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ABSTRACT 


There  is  much  to  be  done  to  update  the  Naval  Reserve 
automated  information  systems  to  1980’s  technology.  This 
thesis  analyzes  the  Naval  Reserve’s  automated  information 
system-  the  Reserve  Training  Support  System  (RTSS) .  It  pres¬ 
ents  the  system’s  background  and  specifications,  its  prob¬ 
lems  and  the  Reserve's  own  plan  to  resolve  these  problems. 
After  a  discussion  on  the  characteristics  of  an  effective 
automated  information  system,  RTSS  is  critiqued.  The  key 
issue  is  the  obsolescence  of  the  hardware  and  software  being 
used.  To  alleviate  their  information  problems,  the 
Reserve's  must  develop  a  plan  to  implement  new  hardware  and 
software  technology  in  a  coordinated  fashion.  An  alterna¬ 
tive  is  presented  to  the  traditional  system  development 
process:  prototyping.  Relational  database  theory  is  briefly 
discussed.  ORACLE,  a  relational  database  management  system, 
is  used  to  implement  the  database  prototype  that  serves  as 
an  example  of  how  current  technology  can  be  used  to  elimi¬ 
nate  many  of  the  Naval  Reserve's  information  problems. 
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I.  INTRODUCTION 

In  this  thesis  we  present  an  approach  for  solving  a 
portion  of  the  A  DP  problems  of  the  Naval  Reserve.  We  have  a 
two-fold  purpose  in  this  effort. 

First,  we  have  a  strong  desire  to  produce  a  usable 
product.  We  want  to  do  something  functional,  while  satis¬ 
fying  the  academic  requirement  for  a  thesis.  To  that  end, 
we  called  on  the  experiences  of  our  advisors  witn  Automated 
Information  Systems  (AIS)  in  the  Naval  Reserve;  specifi¬ 
cally,  their  experience  with  the  Reserve  Training  Support 
System  (RTSS)  .  They  believed  that  much  remained  to  be  done 
in  updating  the  Reserve  Information  Systems  to  1980’s  tech¬ 
nology.  Second,  we  both  have  a  strong  desire  to  use  a 
fourth  generation  relational  language.  One  of  these  commer¬ 
cial  off  the  shelf  products,  ORACLE,  is  installed  on  the 
Computer  Science  Departments  VAX  11/730  computer  at  the 
Naval  Postgraduate  School  and  is  available  for  our  research. 
The  factor  bringing  the  two  togetaer  became  evident  early  in 
our  research  when  we  discovered  that  ORACLE  could  run  on  the 
equipment  being  installed  for  RTSS,  given  an  operating 
system  conversion  or  change. 

In  gathering  the  appropriate  background  information  for 
our  topic  we  were  immediately  presented  with  larger  issues. 
The  concepts  of  strategic  policy  and  organizational  philos¬ 
ophy  in  Information  Systems  management  must  first  be 
addressed  and  resolved  by  an  organization  before  a  new 
computer  system  will  be  effective.  To  have  discussed  just 
the  one  system  in  question  without  discussing  the  issue  of 
the  present  and  future  status  of  Information  Management  for 
the  Reserves  would  have  been  myopic;  too  many  questions 
would  have  been  left  unanswered. 
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Moreover,  ETSS  must  not  be  seen  merely  in  the  short 
sighted  light  of  separate  Reserve  organizational  issues. 
Certainly  the  Reserves  have  unique  mission  requirements; 
they  are  presently  developing  their  own  unique  architectures 
to  meet  advancing  Information  System  Management  issues  head 
on.  But  Reserve  issues  are  Navy  issues.  Navy  problems  are 
Reserve  problems,  and  so  on.  Indeed,  we  believe  our 
research  will  show  that  many  of  the  problems  the  Reserves 
face  today  have  arisen  from  the  lack  of  a  clear  delineation 
of  where  the  Reserves  and  the  Navy's  MS  needs  differ. 

Thus  our  treatise  progresses  from  background  and 
specifics  on  RTSS,  to  a  wider  scope  of  AIS  problems  and 
Issues  facing  the  Reserves,  and  back  to  more  RTSS  specifics. 
Ne  present  kindred  problems  and  issues  for  the  parent  Navy 
using  the  vehicle  of  a  CNO  ordered  blue  ribbon  panel  of 
experts  recruited  by  the  National  Science  Foundation.  Re 
then  address  present  and  academic  design/redesign  strategies 
for  the  Naval  Reserve,  and  introduce  our  choice  for 
attacking  this  problem  of  considerable  scope.  Finally,  we 
invested  a  large  amount  of  time  learning  ORACLE,  and  offer 
this  prototype  as  an  attempt  to  starting  afresh.  Our  proto¬ 
type  is  only  an  example;  it  is  illustrative  of  what  can  be 
accomplished  with  a  fourth  generation  relational  system.  Fe 
think  our  problem  solving  approach  fits  soundly  with  the 
recommendations  of  independent  studies  of  those  larger 
issues. 

Chapter  One  is  an  overview  of  the  thesis,  with  brief 
summaries  of  the  chapters  and  the  thoughts  behind  our 
overall  approach.  It  knits  the  far-reaching  research 
efforts  towarls  a  meaningful  conclusion. 

Chapter  Two  is  a  background  investigation  of  RTSS  (Air)  , 
with  a  brief  look  at  a  concurrent  and  partially  redundant 
system  in  t  ne  RISC  family,  RTSS  (Training  Management).  Ne 
loot  a t.  th»  intended  purposes  and  surrounding  policies  of 
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the  system  as  it  has  grown.  Re  present  the  hardware  and 
software  environments  for  the  system,  and  then  address  the 
progress  and  problems  in  the  Reserves'  implementation 
efforts. 

Chapter  Three  is  the  transition  in  which  we  focus  on  the 
concept  of  information  as  a  resource;  the  ways  the  Navy,  the 
Reserves,  and  specifically  RTSS,  have  dealt  with  this  issue 
are  presented.  We  note  some  exciting  and  ambitious  plans 
for  the  future  as  put  forth  in  the  latest  information 
systems  strategic  plans  for  the  Navy  and  the  Reserves.  We 
then  transition  through  brief  discussions  of  implementing 
current  technology  and  systems  development  methodologies  to 
the  prototyping  concept. 

Chapter  Four  is  the  Prototype.  In  an  effort  to  bring 
the  reader  who  is  unfamiliar  with  relational  databases 
onboard,  we  have  included  a  brief  discussion  of  some  germane 
terms  and  concepts  at  the  start.  We  then  present  a  discus¬ 
sion  of  ORACLE  and  how  we  used  its  features  to  implement  our 
prototype  design.  We  have  taken  some  rather  large  manuals 
for  using  ORACLE  and  condensed  them  into  a  simplified 
approach  to  what  the  system  is  capable  of  doing,  and  what  we 
did  with  it. 

Chapter  Five  is  our  final  conclusions  and  recommenda¬ 
tions.  Included  are  recommendations  for  the  Naval  Air 
Reserve  and  the  path  it  should  take.  Finally,  we  discuss 
the  next  steps  to  be  taken  in  the  development  of  tne 
prototype. 
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E.  SYSTEM  HABD&ARE  EHVIROHMENT 

The  DEC  family  of  PDP-11  computers  is  used  at  RTSS  sites 
in  New  Orleans  and  other  non-ATSS  sites.  The  PDP-11/70  is  at 
New  Orleans,  and  either  PDP-11/23  or  11/50  CPUs  are  at  the 
smaller  sites;  specific  details  of  each  site  configuration 
are  available  in  the  Functional  Descriptions  of  the  RTSS 
systems.  The  follow-on  generation  to  the  PDP-11,  namely  the 
VAX-  1  1/780,  is  being  reguested  in  the  POM  37  for  the  New 
Orleans  RTSS  (TM)  site.  Code  46  (AD?  Plans)  at  CNAVRES  is 
guiding  the  purchase  under  the  umbrella  of  Navy  ADP 
purchasing  reg uirements. 

F.  PROGRESS  TO  DATE 

RTSS  (Air)  presently  consists  of  four  Commander  Naval  Air 
Reserve  Forces  (COHN AVAIRESFCR)  central  sites,  each  of  which 
support  a  number  of  satellite  sites.  The  central  (host) 
sites  are  geographically  spaced  to  serve  the  largest  number 
of  aviation  activities.  In  addition  to  the  central  and 
satellite  sites.  Reserve  aviation  activities  are  co-resident 
on  seven  Regular  ATSS  sites.  95F  of  ail  participating  units 
were  to  be  supported  by  the  end  of  calendar  year  1S34  by 
either  RTSS(Air)  or  ATSS.  [Ref.  6:  p.  1  ] 

Owing  to  its  borrowed  and  aged  nature,  RTSS (Air)  has 
several  drawbacks  to  effective  implementation  in  the  field. 
Since  it  is  tied  so  closely  to  ATSS,  RTSS  implementation 
suffers  any  problems  that  ATSS  is  susceptible  to.  NAVAIP 
support  of  the  ATSS  system  has  finally  increased  to  a  staff 
of  three  after  many  years  of  requests.  Moreover,  the 
initial  premise  in  the  RTSS  (Air)  Functional  Description  was 
that  no  software  modification  costs  would  be  incurred  by  the 
Reserves  because  of  the  Link  to  ATSS.  This  is  faulty  on  two 
courts.  First,  while  the  Reserves  wait  for  updated  software 
instead  of  updating  it  themselves,  they  incur  the 
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CANTRAC  and  MCRF  courses,  and  create,  delete  and 
review  capability  for  non-standard  courses. 

j)  Readiness--allows  for  IPAD  billet  input,  update,  and 
review  by  unit,  Peserve  Program  Number  (RPN),  rating, 
or  designator,  and  generates  diary  entries  for  posting 
to  IMAPMIS.  It  is  linked  to  the  Billet  Maintenance 
subsystem. 

k)  Mobilizat ion-- the  primary  communications  vehicle  for 
reporting  guantitative  unit  mobilization  data  and  unit 
status  information  in  the  event  of  an  actual  mobiliza¬ 
tion  or  mobilization  exercise.  It  is  a  subset  of  the 
files  created  by  the  Billet  and  Active  Activity  files, 
and  is  supposed  to  be  updated  after  every  billet 
update. 

As  of  December  1934,  the  only  subsystems  fully  oper¬ 
ational  were  MATTS,  APTS,  Readiness,  and  Ready  Mariner. 

D.  SYSTEM  SOFTWARE  ENVIRONMENT 

Computer  programs  in  RTSS  systems  must  interact  with  the 
DEC  Resources  Sharing  Timesharing  System/Extended  (EST5/E) 
operating  system.  ESTS/E  is  designed  to  allow  up  to  64 
simultaneous  processes2  to  interactively  access  large 
amounts  of  data.  It  dynamically  allocates  processor  time, 
memory  space,  file  space,  and  peripherals  to  suit  the 
changing  demands  of  the  system.  Development  to  date  has 
been  in  the  BASIC-PLUS  and  BASIC- PLUS-TWO  programming 
languages;  RSTS/E  can  also  support  COBOL,  FORTRAN  IV,  APL, 
and  PPG  II  language  processors. 


2In  a  single  processor  environment  s 
term^  "simultaneous  processes"  means  tha 
handle  separate  user  processes  with  no 
such  that  the  user  things  he  is  the  only 
In  actuality,  if  a  large  number  of  users 
run  simultaneous  processes,  there  would 
order  of  several  seconds. 
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order  writing  systems  for  accurate  data.  It  is  pres¬ 
ently  independent  of  RTSS(Air)  Personnel  software. 

b)  3illet  File  Maintenance — allows  for  review  of  indi¬ 
vidual  or  unit  billets,  and  updates  of  Individual 
Readiness  Assessment  Designator  codes  for  either  indi¬ 
viduals  or  units.  It  is  supposed  to  be  updated  via 
IMAPMIS,  and  maintained  via  MATTS. 

c)  Activity  File  Maintenar.ce--alicvs  for  review  of 
reserve  and  active  activities  by  different  codes 
( RUIC , APC, AU IC) ,  and  update  oy  RUIC  of  reserve 
activity  files.  It  is  to  be  updated  monthly  by 
I M APHIS. 

d)  Mobilization  Assignment  Trainee  Tracking  System 
(MATTS)  —  records  gains,  losses,  transfers,  and  reas¬ 
signments  via  the  three  previous  subsystems. 

e)  Ready  Mariner — tracks  the  flow  of  Ready  Mariner 
personnel  through  the  Naval  Reserves. 

f)  Variable  Report  Generator  Query) --enables  users  to 
develop  and  generate  reports  or  reguests  for  informa¬ 
tion  from  the  database  on  demand. 

g)  Fixed  Reports--enables  the  user  to  generate  certain 
preprogrammed  fixed  reports,  such  as  readiness  and 
mobilization  reports  which  cannot  be  met  through 
Qu  ery . 

h)  Utilities--a  collection  of  software  modules  for  auto¬ 
mating  labor  intensive  manual  operations,  such  as 
producing  mailing  labels. 

i)  A  CD  UTS  A  Request  Tracking  System  (ART  S) -- pro  vi  des 
authorized  users  access  to  tne  RTSS(TM)  ACDUTRA  appli¬ 
cation  files  to  create,  update,  review  and  delete 
applications  and  to  generate  approval,  disapproval, 
cancellation,  and  quota  request  letters  concerning 
these  applications.  It  is  also  to  provide  access  to 
t  iie  Course  Files  with  review  capability  for  standard 
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This  sub-system  was  not  operational  as  of  June  1934. 
It  will  utilize  two  separate  software  components: 

i)  Unlisted  Training  Software--in dividual  training 
records  and  schedules  for  training  syllabi. 

i i )  Aircrew  Software  —  individual  aircrew  training 
records,  schedules  for  student  training  with 
start/stop  dates,  and  long  term  trend  analyses  to 
detect  deficiencies  in  tne  training  program 
itself . 

g)  Resource  Scheduling  Software--types,  quantities,  and 
status  of  training  resources.  It  matches  training 
resources  to  training  needs. 

h)  Resource  and  Configuration  Accounting 

Software--monitors  status  and  configuration  of 

training  aircraft  resources.  It  provides  the  capa¬ 
bility  for  individual  aircraft  maintenance  records, 
and  generates  all  required  periodic  maintenance 

reports. 

At  present,  only  the  Personnel  and  Resource  d 
Configuration  Accounting  Software  are  operating.  The 

Testing  software  is  close  to  implementation.  Another 
subsystem  not  directly  included  in  the  original  Functional 
Description,  Reserve  Training  Tracks,  is  presently  being 
developed  to  map  billet  training  requirements  to  an  individ¬ 
uals  background  and  then  schedule  nim/ner  for  available 
schools  in  an  individual  training  track. 

2.  RTSS  (TM) 

The  FTSS  (TM)  software  consists  of  eleven  system 
functions,  [Ref.  3:  pp.3-5  to  3-18],  in  various  stages  of 

development  at  this  time: 

a)  Personnel  File  Main tenance--allows  for  review  and 
update  of  records  by  individual  or  by  unit.  This 
subsystem  is  linked  to  IMAFMIS,  MATTJ,  and  the  ACDUTRA 
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C.  APPLICATIOSS  SOFTWARE 


1.  RTSS  (Air) 

The  applications  software  for  RTSS  (Air) ,  as  derived 
from  the  original  ATSS  programs,  is  divided  into  the 
following  categories:  Personnel  Qualifications,  Report 

Generation,  Test  and  Evaluations  (TEVS),  Flight  Data, 
Personnel  Scheduling,  Enlisted  Training,  Aircrew  Training, 
and  Resource  Configuration  and  Scheduling  (RCAS)  [Ref-  2:  p- 
1  ].  A  brief  explanation  of  each  follows: 

a)  Personnel  Software — the  cornerstone  of  the  RTSS  (Air) 
database,  with  personal  identification  and  training 
history  data  for  individuals. 

b)  Personnel  Qualification  Standards  (PQS) /Q ua lif ication 
Software--outputs  listings  of  personnel  qualification 
for  specific  tasks  and  the  expirations  of  those  quali¬ 
fications;  not  operational  at  this  writing. 

c)  Report  Generation  Software — a  variable  report  gener¬ 
ator  to  provide  users  with  the  capability  to  retrieve 
records  based  on  a  specified  selection  criterion,  sort 
or  arrange  these  records  in  any  desired  sequence,  and 
generate  reports  with  selected  data  items  from  the 
record. 

d)  Test  and  Evaluation  S of tware--provides  the  capability 
to  create,  update,  review,  and  delete  individual  test 
items  and  generate  printed  tests,  and  provide  optical 
scoring  and  statistics  generation.  This  sub-system  is 
not  operational  at  this  writing. 

e)  Flight  Data  So ftware--aiiows  the  entry  of  yellow  sheet 
data  for  statistical  reports  on  aircraft  and  aircrew 
flight  times. 

f)  Personnel  Scheduling  Subsystem — matches  a  student's 
education  and  experience  witu  the  needs  of  the  service 
and  the  available  training  paths  to  meet  those  needs. 

2  1 


with  the  CNA7SES  HISS  (TM)  centralized  data  base  and 
other  RTSS  (Surface)  units. 

Seven  years  ago,  the  long  term  goal  was  for  total 
integration  of  RTSS  (Surface),  RTSS  (Air),  and  RTSS  (TM) 
into  a  consolidated  and  centralized  database  to  provide 
real-time  information  for  personnel,  mobilization, 
recruiting,  readiness  and  training  management.  At  present, 
the  RTSS  (Air)  and  RTSS  (TM)  are  two  separate  systems 
running  on  two  separate  PDP  11/70  computers  at  New  Orleans. 
Personnel  data  from  the  field  must  be  entered  twice  in  order 
to  keep  data  on  both  systems.  Much  of  the  data,  and  resul¬ 
tant  inaccuracy,  for  RTSS  (TM)  has  come  from  its  dependence 
on  the  Inactive  Manpower  And  Personnel  Management 
Information  System  (IMAPMIS)  for  billet  and  mobilization 
queries.  IMAPMIS  is  acknowledged  to  be  inadequate,  and  is 
presently  under  extensive  redesign1  [Ref.  4:  p.1-14]. 

Informal  correspondence  with  the  RTSS  coordinator  at 
New  Orleans  indicated  a  nopeful  union  of  the  three  RTSS 
systems  within  a  year  by  the  new  contractor,  Martin-Marietta 
Corp.  At  the  same  time,  however,  he  acknowledged  that  once 
the  DEC/VAX  730  equipment  arrives,  all  tne  software  would 
need  to  be  designed  away  from  the  ESTS/E  operating  system, 
and  a  database  more  powerful  than  the  locally  designed  but 
obsolete  one  in  use  would  need  to  be  implemented.  [Ref.  5] 


^See  aiso  Chapter  3:  PROBLEMS,  Naval  Reserve,  under  the 
Loqistics/Shore  Support  Programs  discussion,  and  STRATEGIES, 
under  the  5DS  discussion. 
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h)  Reduction  of  administrative  and  clerical  workload  of 
field,  staff,  and  operating  units. 

2.  RTSS  [TM) 

The  RTSS  (TM)  was  designed  to  support  training 

management,  mobilization  assignment,  readiness  measurement, 
and  mobilization  and  readiness  reporting.  Like  RTSS  (Air)  , 
it  was  to  have  the  capability  to  create  an  individual’s 

record  when  initially  affiliated  with  the  Naval  Reserve  and 

then  to  follow  him/her  throughout  the  reservist's  entire 
service  with  the  Naval  Reserve.  The  long  term  objectives  of 
the  system,  [fief.  3:  pp.  2-2, 2-3  ],  overlap  those  of  RTSS 
(Air)  considerably: 

a)  Increasing  the  quantity  and  quality  of  Selected 

Reserve  mobilization  billet  assignment  capability  at 
all  command  levels. 

b)  Integrating  personnel  and  training  record  data  under  a 
single  system  accessible  from  remote  locations. 

c)  Providing  a  methodology  for  the  real-time  measurement 
and  reporting  of  personnel  training  readiness. 

d)  Increasing  the  efficiency  and  effectiveness  of  sched¬ 
uling  training  for  the  drilling  Reservist. 

e)  Providing  more  timely  and  accurate  information  for 
mobilization  reporting. 

f)  Improving  the  reliability  of  training  information  at 
all  command  levels. 

g)  Reducing  the  administrative  and  clerical  workload  of 
operating  units. 

h)  "Capturing"  input  data  at  the  source,  thereby  elimi¬ 
nating  intermediate  error-inducing  steps. 

i)  Providing  limited  stand-alone  local  processing  capa¬ 
bilities  for  the  Naval  Reserve  Center. 

j)  Providing  an  integrated  comm  unications  capability 
enabling  the  localized  units  to  exchange/update  lata 
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designed  to  be  capable  of  creating  a  trainee's  training 
record  or  acquiring  an  existing  record  from  another  ATSS 
site  when  the  trainee  initially  enters  the  Naval  Reserve, 
maintaining  an  individual's  training  record,  and  monitoring 
the  training  histor y/reguir ements  throughout  the  individu¬ 
al's  entire  service  in  the  Naval  Reserve.  RTSS  (Air)  must 
also  provide  communications  capabilities  to  support  activi¬ 
ties  nationwide.  This  includes  aviation  activities  at  any 
of  eight  Reserve  NASs,  seven  NARs,  and  active  NASs.  It  is 
supposed  to  have  the  flexibility  to  support  both  remote  and 
local  users  via  several  methods:  dial-up,  dedicated  communi¬ 
cations  and  batch  updating  through  exchange  of  information 
with  a  remote  minicomputer,  word  processor,  or  intelligent 
terminal.  The  long  term  objectives  of  RTSS  (Air) ,  [fief.  2: 
p.  1],  are: 

a)  An  increase  in  the  quantity  and  quality  of  Selected 
Reserve  (SELRES)  mobilization  billet  assignments  at 
all  command  levels. 

b)  Integration  of  personnel  and  training  record  data 
under  a  single  system  accessible  from  remote 
locations. 

c)  Reduction  of  time  and  training  resource  requirements 
through  individual  SELRES  diagnostic  testing;  training 
scheduling,  tracking,  and  reporting;  individualized 
instruction;  and  maintenance  and  administration  of 
syllabi  and  courseware. 

d)  Reduction  of  time  required  for,  and  increase  in  accu¬ 
racy  of,  development  of  data  for  mobilization. 

e)  Monitoring  personnel  readiness  status. 

f)  Improvement  in  the  effectiveness  and  efficiency  of 
tracking  trainee  progress. 

g)  Improvement  in  the  reliability  of  training  information 
at  all  command  levels. 
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ongoing  USN  training  initiatives  and  provide  compatibility 
with  a  standard  active  duty  computer  system.  In  addition, 
some  cost  avoidance  would  be  realized  from  the  sharing  of 
resources  when  active  USN  and  Reserve  aviation  activities 
were  co-located  at  existing  ATSS  sites.  Further  savings 
would  be  realized  by  adopting  an  already  existing  system  and 
avoiding  the  time-consuming  and  expensive  systems  develop¬ 
ment  process. 

For  funding  and  control  purposes  the  system  was  renamed 
the  Reserve  Training  Support  System  (RTSS)  .  It  consisted  of 
three  major  component  systems:  RTSS (TM)  for  training  manage¬ 
ment,  RTSS  (Surf ace)  for  surface/ashore,  and  the  RTSS  (Air) 
for  aviation.  CNAVRESINST  5230,  [Ref.  2:  p.  1],  established 
policy  for  the  development  as  follows: 

The  Reserve  Training  Support  System  (RTSS)  is  an  auto¬ 
mated  training  management  support  system.  The  purpose 
of  the  system  is  to  provide  training  management  support 
to  field  Naval  Reserve  training  administrators  and  to 
increase  the  quality  of  training  readiness  information 
reporting  at  all  Naval  Reserve  Command  levels.  A  dual 
system  approach  will  provide  for  a  field  training  system 
in  support  of  Naval  Reserve  field  administrators  and  a 
Regional  Training  Management  System  in  support  of  staff 
functions. 

1.  RTSS  (Air) 

The  component  of  RTSS  known  as  RTSS  (Air)  is  designed 
to  support  personnel  training  and  training  management  at 
aviation  activ it ies--NASs,  Naval  Air  Reserves  (NAPs)  ,  and 
Reserve  Forces  Squadrons  (RESFORONS).  This  includes  active 
duty  as  well  as  drilling  Reserve  personnel.  The  system  was 
designed  to  support  multiple  training  needs — formal  schools 
programs,  On-the-Job-Training,  initial  training  for  Ready 
Mariner  (RM)  personnel,  refresher  training  for  veterans 
gained  to  the  Naval  Reserve  after  leaving  active  military 
service,  and  combat-ready  training  for  RESFORONs.  It  is 


be  more  cost  effective  than  a  brand  new  system  could 
initially  provide.  This  is  the  first  of  many  instances 
where  outside  agencies  recommended  that  the  ATSS/RT3S  family 
be  expanded  to  include  more  than  just  its  limited  training 
application.  These  agencies  have  recognized  that  training 
is  only  one  step  towards  achieving  the  organization's  goal 
and  that  many  other  functions  should  also  be  automated.  CNO 
concurred  with  the  findings  of  the  study,  [Ref.  1:  p.19], 
with  a  lesser  degree  cx  urgency  than  implied  in  the  study: 


ATSS,  as  it  exists  today,  meets  the  intent  and  scope  of 
an  automated  information  system  and  should  be  managed, 
developed,  acquired,  and  funded  under  ADP  rules  ana 
regulations.  However.  one  point  must  be  emphasized. 
Regardless  of  ATSS  status,  it  remains  to  be  determined, 
through  detailed  feasibility  studies  and  economic  anal¬ 
yses,  to  what  extent  other  svstems  can  be  accommodated 
and  savings  achieved  without  degrading  the  primary  func¬ 
tion  of  providing  highly  trained  and  qualified  fleet 
replacement  personnel  for  the  aviation  community. 

CNO  will  take  the  necessary  action  to  remove  the  ATSS 
exemption  from  A  DPE  regulations  consistent  with  an 
orderlv  transition  scheme  so  as  not  to  disrupt  ongoing 
ATSS  efforts. 


ATSS  is  now  finally  under  the  ADP  umbrella,  and  is  us 
OPN  dollars  for  funding.  The  transition  of  the  ATSS  Prog 
from  the  Naval  Weapons  Center  to  the  Navy  Management  Syst 
Support  Office  (NANMASSO)  should  start  in  FY  85,  w 
NAVMASSO  picking  up  responsibilities  for  contracting 
software  development. 
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B.  RTSS 


The  Chief  of  Naval  Reserve  became  intereste 
a  viable  training  and  administration  tool  for  it 
as  early  as  1977.  ATSS  was  chosen  as  the 
effective  method  to  achieve  its  required  person 
and  training  management  support.  Justificat 
selection  was  that  it  would  align  the  Naval 
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route  because  all  of  the  ATSS  (and  RTSS)  software  is  tied  to 
RSTS/E. 

During  Fiscal  Fear  1978,  the  Office  of  the  Comptroller 
of  the  U.  S.  Navy  (NAVCOMPT)  reviewed  the  ATSS  exemption 
status  and  ruled  that  ATSS  was  not  a  training  device  as 
defined  by  Department  of  Defense/Department  of  the  Navy 
budget  policy.  NAVCOMPT  and  CNO  reclassified  ATSS  as  a 
computer-assisted  training  system  within  the  generic 
category  of  equipment  configured  solely  for  training  appli¬ 
cations.  NAVCOMPT  authorized  continued  appropriation  of 
ATSS  hardware  and  software  via  Naval  Aviation  Procurement 
funds  (AFN) ,  predicated  on  ATSS  being  used  solely  for  avia¬ 
tion  training  applications  with  no  other  expansion  capabili¬ 
ties  in  the  future. 

A  Naval  Audit  Service  study  completed  in  1980,  £Ref.  1], 
found  ATSS  development  and  acquisition  generally  satisfac¬ 
tory.  Two  areas  were  mentioned  where  improvement  could  be 
made : 

1.  Opportunities  exist  for  reducing  costs  by  benefi¬ 
cially  employing  ATSS  hardware  and  software  for 
requirements  of  other  related  information  systems  and 
by  manning  operational  sites  with  government  vice 
contract  employees. 

2.  Improvements  can  be  made  in  fund  administration  and 
in  the  integrated  logistic  support  areas  of  planning 
and  configuration  control. 

The  study  determined  that  CNO’s  refusal  to  expand  ATSS 
was  based  on  the  perceived  need  to  maintain  ATSS  exemption 
status  under  the  ADPE  acquisition  regulations.  It  found 
also  that  this  exemption  is  r.o  longer  needed,  because  the 
final  10  ATSS  software  systems  to  be  purchased  were  ordered 
under  a  FY  1980  contract.  The  general  conclusions  stated 
that  the  benefits  of  expanding  the  inherent  capabilities  of 
the  ATSS  software  to  allow  for  additional  field  uses  would 
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By  1975,  the  system  was  designated  ATSS  for  management 
control,  and  the  Weapons  Center  still  holds  development 
control  over  the  ATSS  software. 

A  hardware  upgrade  to  the  PDP-11/70  followed,  allowing 
expansion  of  the  101  data  items  to  509,  and  signalling  the 
advent  of  Version  Two  of  the  software.  The  original  file 
structure  became  inadequate.  Versiou  Three  software  design 
began  in  1976  at  five  operational  sites.  The  intent  was  to 
eliminate  some  redundancies  and  clearly  differentiate  sepa¬ 
rate  functional  areas  into  subsystems.  A  phase-in  approach 
was  used  for  Version  Three  design  and  development.  This 
substantially  increased  the  capabilities  of  the  system,  but 
failed  to  achieve  the  total  integration  required.  It  lacked 
the  flexibility  needed  as  the  uses  of  the  system  gradually 
expanded.  Thirteen  subsystems  have  since  evolved  from  these 
beginning  efforts;  Version  Four  of  the  software  was  designed 
to  solidify  and  integrate  these  subsystems  into  a  functional 
and  expandable  system  incorporating  a  Data  Elements 
Dictionary,  easier  program  maintenance  procedures,  and  a 
more  accurate  software  configuration  control.  At  this 
writing,  version  four  software  was  still  under  development. 

large  ATSS  sites  were  upgraded  to  the  VAX-11/780  CPU,  a 
32-bit  machine  capable  of  a  4-gigabyte  program  address 
space.  The  same  KSTS/E  operating  system  was  used  instead  of 
the  more  versatile  Virtual  Memory  System  (VMS)  operating 
system  designed  specifically  for  the  VAX-11/790.  RSTS/E 
burdened  the  normally  efficient  VAX  computer  and  these  ATSS 
sites  did  not  realize  a  significant  increase  in  computing 
performance  over  the  old  PDP  11/70's.  All  attempts  to 
improve  the  RSTS/E  software  so  it  would  not  diminish  the 
VAX’s  efficiency  failed  and  NAVAIR  finally  returned  the  VAX 
computers  for  more  PDP  11/70’s.  NAVAIR  intends  to  keep  the 
RSTS/E  operating  system  and  attempt  to  improve  it  until  it 
is  efficient  enough  for  the  VAX.  They  have  decided  on  this 


(VTS) .  The  Naval  Air  community  currently  uses  A TS3 ;  the 
submarine  community  uses  the  VTS  identif ication ;  the  Reserve 
community  named  their  adaptation  RTSS;  all  systems  have  the 
same  basic  configuration. 

The  Digital  Equipment  Corporation  (DEC)  PDP-11/40 
computer  was  selected  as  the  initial  mi ni -computer  for  CNF. 
Ordered  in  late  1971,  it  was  procured  through  a  competitive 
contract  as  a  turnkey  training  device,  i.e.,  the  contractor 
was  responsible  for  all  installation,  and  only  had  to  "turn 
the  key"  on  before  handing  it  over  to  the  Navy.  The  system 
was  exempted  from  the  complex  and  lengthy  Automatic  Data 
Processing  Equipment  (ADPE)  approval  requirements  by  the 
Chief  of  Naval  Material  because  it  was  designated  solely  a 
training  device.  The  test  and  evaluation  was  done  for 
VA-122  and  two  other  operatioral  A-7  squadrons.  The 
computer  was  installed  in  mid-  1972.  The  LTV  software  devel¬ 
oped  in  Dallas  was  used,  with  software  development  contin¬ 
uing  on-site.  Data  and  operating  files  were  generated  for 
FRAMP  and  the  operational  squadrons.  Evaluation  of  the 
prototype  was  successfully  completed  in  1973. 
Administrative  personnel  from  other  Naval  Air  activities 
visited  the  CMP  at  NAS  Lemoore  and  were  given  a  demonstra¬ 
tion  of  the  system. 

CMP’s  name  was  changed  to  PMS  during  this  time.  In 
December  1973  the  Naval  Weapons  Center  at  China  Lake  took 
control  of  development  and  implementation  of  the  project. 
Its  job  included: 

1.  Anticipating  the  training  needs  of  the  various  Fleet 
activities. 

2.  Observing  and  evaluating  training  methods  and  proce¬ 
dures  both  before  and  after  installation. 

Determining  the  expansion  required  to  maintain  a 
satisfactory  level  of  training  readiness  in  all  areas 
supported  by  the  system. 
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II.  BACKGROOND/E VOLOriOH  OF  RTSS 


A.  HISTORY 

The  Reserve  Training  Support  System  (RTSS)  is  essen¬ 
tially  the  same  as  the  active  duty  system  known  as  the 
Aviation  Training  Support  System  (ATS5) .  The  ATSS  concept 
was  devised  early  in  1971  by  the  Ling  Temco  Vought  (LTV) 
Aerospace  Corporation  to  aid  training  coordination  and 
scheduling  at  one  of  the  Navy's  A-7  aircraft  Fleet  Seadi:  ess 
Squadrons  (FRS),  Attack  Squadron  One  Hundred  Twenty-Two 
(VA-122)  at  the  Naval  Air  Station  at  Lemoore,  California. 
The  initial  version  was  tested  at  VA-122's  Fleet  Readiness 
Aviation  Maintenance  Personnel  (FRAU?)  Department.  The 
primary  job  of  a  FRAMP  Department  at  an  FRS  was  to  ensure 
that  enlisted  aviation  maintenance  personnel  were  provided 
to  fleet  operational  squadrons  adequately  trained  to  perform 
their  jobs.  The  original  goal  of  the  system  was  to  provide 
a  training  support  system  oriented  toward  enlisted  aircraft 
maintenance  training,  and  was  developed  out  of  a  need  for 
relief  in  assigning  courses  and  classes  and  tracking 
students.  ATSS  also  alleviated  the  manual  generation  of 
reports,  forms,  and  other  paperwork  associated  with  a  major 
training  syllabus.  It  was  initially  a  small  software 
package  consisting  of  20  programs  designed  to  manage  101 
data  items  concerning  the  receipt,  transfer,  and  course/ 
class  assignment  of  enrolled  and  future  FRAMP  students. 

The  early  success  of  ATSS  led  to  adaptations  by  otiier 
communities.  The  system  has  had  a  number  of  titles  associ¬ 
ated  with  it  since  1971:  originally  known  as 

Computer-Managed  Personnel  (CMP)  System,  then  Personnel 
Management  System  (PUS),  and  then  Versatile  Training  System 
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RTSS  Geographical  Distribution 


quantifiable  dollar  costs  and  non-quantif iable  readiness 
costs  of  maintaining  dysfunctional  or  manual  systems. 
Second,  even  when  the  software  is  received,  it  requires  some 
massaging  to  fit  the  Reserves  own  unigue  needs.  The  Fiscal 
Year  1984  Reserve  budget  allowed  for  little  else  than  main¬ 
tenance  of  software;  the  Fiscal  Year  1985  budget  was  cut  in 
half,  but  will  allow  for  some  improvement. 

A  new  contractor,  Martin-Marietta  Corporation,  is  in 
place  as  of  the  beginning  of  Fiscal  Year  1985.  Software 
development  and  hardware  installation  efforts  for  ATSS/RTSS 
were  abridged  appreciably  during  the  contract  negotiation 
and  letting  process  from  July  1983  -  September  1984. 
Periodic  continuance  renewals  of  the  previous  contract  with 
the  Syscon  Corporation  served  only  to  keep  a  maintenance  man 
or*  at  existing  sites,  but  delayed  needed  consulting  and 
development  services. 

ether  difficulties  include  the  delays  that  the  Naval 
Weapons  Center  is  experiencing  in  getting  the  new  version  of 
RSTS/E  implemented;  it  seems  that  Martin-Marietta  does  not 
have  the  appropriate  maintenance  contract  with  Digital 
Equipment  Corporation  for  operating  system  updates.  Also, 
as  a  result  of  drawn-out  contract  negotiations,  there  are 
three  month  delays  before  software  changes  can  be  issued 
through  the  new  contractor.  Additionally,  the  ATSS  software 
still  cannot  track  personnel  at  changing  sites.3 

Emphasis  for  implementation  of  the  RTSS  program  through 
1984  by  CNAVSE3  has  been  in  procurement  and  installation  of 
hardware  and  peripherals  at  the  various  sites.  This 
emphasis  is  now  shifting  toward  bringing  software  on-line 
and  beginning  user  training.  Implementation  has  been  slow 


3Ke  found  an  ironic  anecdote  in  our  ATSS  background 
research:  according  to  the  minutes  of  the  September  84  ATSS 
Configuration  Advisory  Board  Meeting,  several  users  volun¬ 
teered  their  services  to  NAVAIR  as  model  managers  in  evalu¬ 
ating  commercial  off-the-shelf  software.  Somebody  beat  us 
to  the  punch,  at  least  in  spirit.  See  [Ref.  7:  p.  2]. 
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due  partly  to  the  newness  of  ADP  to  the  Reserves,  but  more 
so  to  the  annual  funding  constraints  ana  contractor  negotia¬ 
tion  problems  of  ATSS.  At  this  writing,  a  development 
hiatus  of  several  months  caused  by  a  major  budget  slashing 
of  contractor  support  has  finally  been  cleared  up;  CNA7RES 
is  slowly  forging  ahead. 

Networking  capabilities  from  field  sites  to  New  Orleans 
are  still  in  the  planning  stages.  While  it  was  initially 
hoped  that  a  DEC  product  known  as  DECnet  would  serve  as  an 
adeguate  off-the-shelf  candidate  for  the  interface  software, 
development  and  implementation  of  the  Defense  Data 
Network  (DDN)  have  precluded  a  stand-alone  network. 
OPNAVINST  2070.4  of  7  tfarch  1984  has  mandated  that  ADP 
systems  requiring  long  haul  data  communications  include 
provisions  for  using  the  DDN  as  their  primary  data  communi¬ 
cations  medium.  Attempts  by  CNAVSES  Code  46  (AD?  Plans)  in 
mid-1984  to  waiver  RTSS  from  this  Defense  Communications 
Agency  requirement  were  unsuccessful.  Code  4  6  has  since 
been  investigating  the  necessary  means  by  which  to  comply, 
including  soliciting  bids  for  protocol  conversions  for  the 
ESTS/E,  RTSS,  and  DDN  interface. 

In  addition  to  the  above  software  and  hardware  problems, 
we  uncovered  many  deficiencies  in  computer  support. 
Specifically,  no  clearly  written  users  manual  was  or  is  now 
in  existence  for  RTSS  (Air).  No  funding  for  revising, 
updating,  editing,  or  rewriting  the  old,  existing  manuals  is 
available  at  this  time.  The  instructions,  manuals,  and 
minutes  of  meetings  that  we  read  in  our  research  stressed 
that  RTSS  (Air)  is  a  training  system,  placed  in  the  field  for 
the  benefit  of  the  user;  usage  is  limited  to  training 
oriented  subjects,  and  any  use  whicn  cannot  be  directly 
related  to  the  training  of  aviation  personnel  cannot  be 
supported  on  this  system.  The  assertions  were  unclear  given 
that  ATSS  is  now  under  Navy  AD?  guidelines. 
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as  seen 


Other  specif  ic  problems  with  the  RTSS  system  (s)  , 
by  the  users  and  the  experts,  will  be  addressed  with  the 
larger  issues  of  AIS  management  in  the  next  chapter. 
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III.  AUTOMATED  INFORMATION  SYSTEMS 


A.  INTRODUCTION :  THE  7 ALOE  OF  INFORMATION 

The  Naval  Reserve  is  the  recognized  backbone  of  a  strong 
mobilized  nation  when  all-out  war  occurs.  It  is  now  wres¬ 
tling  with  the  nontrivial  questions  of  meeting  distributed 
real-time  personnel  and  mobilization  information  requests. 
In  its  information  processing  arena,  however,  it  faces  many 
of  the  endemic  organizational  problems  of  a  still  young 
computer  age:  lack  of  an  implemented  top  down  design 
strategy,  and  possession  of  antiquated  hardware  and  soft¬ 
ware.  The  software  for  its  RTSS  (Air)  project,  derived  from 
the  initial  Aviation  Training  Support  System,  was  developed 
in  an  era  when  computers  were  used  only  for  data  collection, 
processing,  and  storage.  Used  only  as  a  computing  device,  it 
had  limited  strategic  management  value;  at  that  time  there 
was  no  intent  for  a  correlation  between  strategic  objectives 
and  computer  system  utilization.  Its  value  as  a  decision 
making  tool  in  helping  to  evaluate  training  and  mobilization 
readiness  was  and  is  extremely  limited. 

Today  information  is  a  powerful  tool  that  influences  the 
health  and  well-being  of  all  organizations,  government  or 
business.  Members  of  a  1933  blue  ribbon  panel  appointed  to 
study  the  Navy's  utilization  of  automatic  data  processing 
equipment  unequivocally  stated:  "Virtually  every  action  by  a 
commander,  manager,  or  administrator  in  the  Navy,  as  in  any 
large  organization,  involves  the  acquisition  and  under¬ 
standing  of  information:  information  about  the  organization, 
about  its  status,  about  its  resources,  about  its  environ¬ 
ment.  His  actions  usually  result  in  the  creation  and  promul¬ 
gation  of  policies  and  directives."  [Ref.  8:  p.  2] 
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Information  is  a  key  resource  in  both  the  develop ment 
and  execution  of  organizational  strategies.  In  this  context, 
it  is  essential  to  develop  an  information  system  based  on 
the  strategic  objectives  and  direction  of  the  organization 
[Ref.  9:  p.  39].  While  it  is  the  task  of  the  lower  levels 
of  the  organization  to  collect  data  and  organize  it  in  a 
meaningful  form,  it  is  the  role  of  the  strategic  planners  to 
define  the  scope  of  the  desired  information. 

The  use  of  computerized  information  systems  has  greatly 
aided  the  collection,  compilation  ,  and  presentation  of  data 
and  information.  The  collection  process  is  no  longer  a 
difficult  or  costly  task.  As  a  result,  there  is  a  prolifer¬ 
ation  of  available  data  that  must  be  converted  into  useful 
information  and  analyzed.  Managers  at  different  levels  of 
an  organization  require  different  information.  Managers 
must  be  able  to  extract  information  relevant  to  their  realm 
of  decision  making.  Information  management  must  emerge  as  a 
critical  discipline  for  an  organization's  strategic 
decision-making  process. 

Information  management  must  be  an  aggressive  program 
that  presents  the  correct  amount  of  substantive  information. 
In  dealing  with  the  volume  of  information,  more  information 
will  enhance  decisions  up  to  a  certain  point;  beyond  that,  a 
law  of  diminishing  returns  sets  in.  To  gather  the  correct 
amount  of  information,  managers  must  understand  how  to 
effectively  use  current  and  predicted  future  technology. 

For  the  remainder  of  the  chapter  we  will  address  this 
technology  issue  and  some  specific  problems,  past  and 
present,  for  the  Navy  and  Naval  Reserve,  and  present  the 
latest  Information  System  Strategic  Plans  for  the  Navy  and 
the  Reserves.  We  will  present  a  mixture  of  design  (rede¬ 
sign)  strategies  to  cope  with  design  problems,  and  recommend 
a  state  of  the  art  problem  solving  approach  that  we  found 
viable,  functional,  and  relatively  immediate. 
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B.  PROBLEMS 


1 .  Naval  Reserve 


The  onslaught  of  new  computer  technolog/  in  the  last 
20  years  remains  clearly  in  the  headlines.  Unfortunately, 
the  depth  to  which  this  advancing  technology  can  permeate  to 
the  field  level  in  agencies  as  large  and  complex  as  DGD  or 
the  Reserves  is  constrained  by  educational,  fiscal  and 
bureaucratic  methodologies  that  stifle  initiative  and  reward 
stagnation  and  the  status  yuo.  A  January  1984  study. 
Analysis  of  Naval  Reserve  Force  Information  System 
Management  Requirements,  was  both  blunt  and  specific  in  its 
cited  problem  areas  and  recommendations.  The  list  of  prob¬ 
lems  could  be  a  primer  for  a  ’what  not  to  do’  Information 
System  reference  book. 

First,  they  saw  no  single  organization  taking 
responsibility  for  the  automated  information  systems  in  use 
by  the  Naval  Reserve.  Many  of  the  systems  are  the  result  of 
"favors''  or  "hand-me-downs"  from  others,  and  in  most 
respects  not  well-designed  for  Reserve  use  because  they  were 
never  intended  for  this  community.  The  lack  of  account¬ 
ability  resulting  from  AIS  functional  sponsorship  of  Reserve 
systems  by  other  commands  has  been  a  major  contributing 
factor  to  the  current  inadequate  state  of  Reserve  informa¬ 
tion  systems.  [Ref.  10:  p.  2-3] 

Second,  the  bureaucratic  headache  of  Life  Cycle 
Management  resulting  from  the  Brooks  Act  of  1965  and  subseq¬ 
uent  directives  addresses  only  the  issues  of  AIS  acquisition 
and  development  plans.  The  need  to  view  information  as  a 
resource  in  an  overall  Information  Systems  Management  Plan 
is  lacking. 

Third,  current  Reserve  AISs  do  not  get  the  job  done. 
They  do  not  contain  ail  the  data  needed  for  desired  moni¬ 
toring  and  control  functions.  They  do  not  provide  for  eas^ 


information  retrieval  in  desired  formats.  They  currently 
contain  duplications  of  data,  with  inconsistencies  in  defi¬ 
nition  processing  and  data  entry  which  lead  to  confusion 
and/or  inaccurate  measures  of  ef fectiveness .  The  present 

systems  were  developed  mostly  during  a  period  when  available 
hardware  and  software  were  more  expensive  and  had  less  capa¬ 
bility.  They  were  usually  a  response  to  a  crisis  management 
need  and  often  developed  with  virtually  no  user  interface. 
[Ref.  10:  p.  3-1  ] 

Fourth,  staff  proficiency  in  ATS  planning  and  lead¬ 
ership  was  nonexistent.  In  the  finding’s  words:  "So  if  the 
distributed  a rchitecture. .  .  recomaended. . . is  to  become  a 
reality,  it  is  through  the  ’hands  on'  involvement  of  line 
management  on  the  staff  and  in  field  activities"  [Ref.  10: 
p.  3-5].  Effective  use  of  new  hardware  and  software  tech¬ 
nologies  guided  by  proper  application  of  information 
resource  management  skills  must  be  the  approach  for  the 
leaders  of  the  80s  and  90s. 

Among  several  specific  organization  realignment 
suggestions,  a  fifth  and  major  recommendation  was  for  the 
development  of  a  long  range  technical  architecture  for 
information  systems  [Ref.  10:  p.  4-6],  It  is  to  be  based  on 
a  distributed  model  whose  major  components  are: 

a)  Electronic  workstations 

b)  Distributed  computer  system  hosts 

c)  An  advanced  electronic  data  network 

Perhaps  the  strongest  and  most  important  recommenda¬ 
tion  the  study  put  forth  was  to  adopt  as  a  goal  for  long 
range  planning  purposes  "the  ability  of  all  members  of  the 
Reserve  claimancy  to  accomplish  their  assigned  tasks  with 
the  assistance  of  automated  information  systems"  [Ref.  10: 
p.  4-2]. 

To  illustrate  the  concept  of  information  as  a 
resource  in  the  Reserves,  some  examples  of  present  day 
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effectiveness  are  pertinent.  In  their  preliminary  draft  of 
an  Information  Systems  Plan  for  CQMNA7RESF0R ,  tae  team  noted 
deficiencies  of  various  Automated  Information  Systems  as 
they  related  to  functional  needs.  Among  them: 

a)  Fleet  Programs 


The  total  picture  of  I.S.  use  in  Fleet  Programs,  but 
equally  in  Logistics/Shore  Support  Programs  and  Staff 
Programs,  is  one  of  solutions  to  information  needs,  and 
partial  redundancies  and  dissatisfaction  with  the  accu¬ 
racy,  timeliness,  format,  and  ultimate  usability  of  the 
information  received.  The  dominant  perception  through 
the  31  and  32  divisions  <Programs  and  Training  Support> 
is  expressed  in  the  remark  or  one  Program  Manager  that 
'much  of  the  time  we  seem  to  be  working  for  the 
computer  rather  than  the  computer  for  us'.  f fief .  10: 
Appendix  4-46] 


b)  Logistics/Shore  Support  Procrams 


RTSS ( TM) ,  used  for  such  purposes  as  obtaining  billet 
listings  to  determine  allowances  and  field  inquiries 
about  billets,  as  well  as  for  addresses  aud  address 
labels,  is  xess  than  satisfactory  as  a  provider  of 
required  data.  Two  program  managers  in  fact  trv  to 

minimize  reliance  on  it  due  to  unavailability  of  the 
sorts  most  useful  in  program  management  (e.g.  alphabet¬ 
ical  by  type  of  unit)  ,  and  the  system’s  slowness.  The 
hand  sort  which  two  program  managers  presently  revert  to 
takes  approximately  fo lr  hours.  A  program  manager  who 
does  relv  on  P.  TSS(TM)  counts  on  a  one-day  delay  to 
receive  requested  output.  Since  that  often  is  not  scon 
enough  for  fielding  senior's  inquiries,  one  result  is 
that  great  volumes  of  paper  are  kept  from  which  to 
generate  manual  reports.  code  3124  relies  for  much  of 
their  data  on  a  report  completely  outside  the  organiza¬ 
tion,  a  NAVSDP  report  which  aggregates  manning  data  on 
NA7 SUP— supporting  units,  since  it  is  more  accurate  and 
timely. 

A  further  shortfall  in  RTS5(TM1  at  present  is  that  some 
data  fields  are  not  or  are  infrequently  undated  (for 
example.  education,  address  and  telephone  numbers). 
Fields  that  are  never  updated  would  better  be  removed 
from  the  system  altogetner,  in  some  officers'  estima¬ 
tion,  in  that  wrong  data  often  are  more  deleterious  in 
their  effects  than  no  data  at  ail.  [Ref.  10:  Appendix 
4-47,4-48  ] 


c )  Staff  Prog  rams 


Lack  cf  accuracy  and  completeness  are  a  continuing 
problem,  with  monthly  reports  fregueatly  at  variance 
with  manually  maintained  figures  by  20%  or  mor e . . . . 5hor t 
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term  emergency  mobilization  needs,  such  as  drenada  and 
Lebanon,  essentially  must  be  managed  with  manual  tech- 
nigues  due  to  lack  of  responsive  terminal  facilities  and 
an  accurate  mobilization  database.  [Ref.  10:  Appendix 
4-49,4-50] 


d)  Flight  Support 


The  RTSS  (Air)  software  is  behind  the  times  in  format  and 
content  -  content  too  old  for  flight  reports.  The  time¬ 
liness  of  these  content  data  wirl  be  enhanced  through 
modification  to  process. 

Sode  55  <Flight  Support>  has  a  need  to  transfer  informa¬ 
tion  from  system  to  system  in  a  rapid  manner  to  facili¬ 
tate  management  decisions.  This  need  affects  55’ s 
managerial  effectiveness. 

An  example  of  this  sort  of  concern  is  the  inability  of 
55  to  gain  access  to  requirements  except  NECs  waich 
helps  but  an  individual’s  experience  is  the  more  impor¬ 
tant  access  so  far  as  readiness  is  concerned.  r  Hef .  10: 

Appendix  4-52] 


Navy 


The  Navy  did  not  escape  the  scrutiny  of  close  obser¬ 
vation  of  its  AD?  sins.  The  blue  ribbon  panel  funded  by  the 
National  Research  Council  found  that  the  entire  Navy  was 
operating  with  "computing  equipment  produced  in  the  1960’s", 
and  too  little  attention  being  paid  to  "policy  development 
and  strategic  planning. .. <a nd>  to  the  potential  of 
mana gement- level  information  systems"  [Ref.  8:  pp.  4,5], 

The  panel  published  a  number  of  findings  in  a  narrative 
formatted  ten  page  chapter  of  the  report.  The  following 
points  are  pertinent  to  the  Reserves’  implementation  and 
expansion  of  a  14  year  old  borrowed  system,  and  are  quoted 
verbatim  from  the  report: 
a)  Hardware 


Kany  problems  arise  when  obsolete  equipment  is  allowed 
to  remain  in  operation.  First,  tie  cost  of  operation 
and  maintenance  is  much  higher  for  an  early-generation 
machine,  compared  to  that  for  a  current- generation 
system  of  equal  capacity.  Savings  in  energy,  floor 
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space,  and  maintenance  can  usually  repay  toe  purchase 
cost  of  a  new  central  processor  in  less  than  two  years. 
Reliability  and  repaira bi litv  is  far  superior  for 
current-generation  equipment.  Policies  that  encourage 
reusing  old  equipment  ao  not  properlv  recognize  these 
potential  savings. 


b)  Software 


A  more  difficult  concept  is  that  software 
lete  just  as  surely  as  does  equipment 
replacement  is  usually  viewed  as  a 

project,  necessary  to  improve  reliabiii 
ability, and  operability.  But  modernizing 
failing  to  question  wnether  software  is 
really  addresses  only  a  part  of  the 
problem. 
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computina  system,  important  capabilit 
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tion.  When  a  system  is  modernized,  us 
ously  question  whether  the  software  sy 
relevant  to  their  information  needs, 
software  should  be  designed  to  exploit 
of  the  new  equipment.  Thus,  by  incorpo 
ware  that  permits  on-line  access  to  a 
instead  of  an  older  system  of  numerou 
programs,  the  jobs  of  cierks  and  manager 
signed,  perhaps  greatly  reducing  errors 
costs.  The  resulting  software  syste 

useful,  more  efficient  in  terms  of  la 
resources,  and  truly  exploitive  of  t 
which  it  runs.  [  Hef.  8:  pp.  10-11] 
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Commander,  Naval  Reserve  Force  is  one  or  t..*  .^x  -c..eior.  2 

commands  encompassed  in  the  MAPII5  ianct  10;  .a  A  cor.manj.ty. 

The  Reserves’  involvement  as  an  echelon  i  command  in  -..is 
regard  is  limited  to  those  AISs  specified  in  Me  moron  Jams  of 
Agreement  with  OP-01;  RTSS  is  one  of  those  systems. 

[Ref.  4:  p.  iii] 

The  Program  Objectives  Memorandum  for  1987 (POM  87) 

MAPTIS  Program  Strategic  Plan  is  an  extensive  work  that  says 
all  the  right  things  for  correcting  the  wrongs  of  AIS  prob¬ 
lems.  It  lays  out  ambitious  and  challenging  guidelines  by 
which  it  intends  to  progress  for  the  Fiscal  Years  87-91.  The  i 

document  is  most  encouraging  in  tone  with  regard  to  AIS 

« 

planning: 

The  functional  community's  dependence  on  the  use  of 
automated  information  support  has  reached  a  point  where 
it  has  become  critical  to  MPT  mission  acco mplishmen t 
[  Ref.  4:  pp.  iii  ]. 

Paramount  to  insuring  sound  information  system  planning 
is  a  direct  relationship  to  front-end  mission  planning 

[Ref.  4:  pp.  iv]. 

The  rapid  pace  of  change  in  ADP  technology  must  be 

planned  for  if  we  are  to  avoid  obsolescence  [Ref.  4:  pp.  i 

2-34].  L  v  : 

> 

The  plan,  which  provides  information  support  goals  and  ] 

i 

objectives  to  the  MPT  commands,  is  the  vehicle  for  communi¬ 
cation  and  concurrence  between  MPT  functional  managers  and 
MAPTIS  information  support  managers.  It  has  four  major  goals  ; 

defined  and  established: 

a)  Achieve  an  Effective  and  Efficient  Operational  Posture 

b)  Improve  the  Management  of  Resources 

c)  Integrate  Modern  Information  Technology  into  the 
MAPTIS  Program 

d)  Improve  the  Quality  of  MPT  Data  and  Information  ; 

An  adjunct  guideline  to  this  document  cites  the  DCD 

thrust  to  improve  productivity  and  mission  performance  in 
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meeting  the  above  goals  through  the  application  of  end  user 
computing  technology,  i.e.,  microcomputers.  This  Department 
of  the  Navy  (DON)  document  encourages  MAPTIS  program  managers 
to  "incorporate  end  user  computing  technologies,  as  mucn  as 
possible,  into  the  MAPTIS  Program  as  a  cost-effective  method 
of  distributing  information  processing  support  to  functional 
users."  [  Eef .  11:  p.3] 

Getting  back  to  the  POM  87  plan,  the  Reserves  are 
specifically  singled  out  as  one  of  the  major  challenges  in 
meeting  the  DCNC's  objective  of  improving  fleet  readiness  by 
continuing  to  effectively  and  efficiently  fulfill  manpower 

requirements.  Along  with  a  trained  active  force  and 

« 

increased  emphasis  on  contractors  and  civilian  employees, 
the  plan  cites  the  intent  to  expand  the  Naval  Peserve  over 
the  next  five  years  so  that  it  will  be  able  to  taxe  over 
missions  from  the  active  force.  It  stated  unequivocally: 
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One  of  the  strategic  goals  of  the  plan  is  for  a  central 
pay  and  personnel  system  called  the  Source  Data  System 
(SDS).  With  a  pilot  site  in  place  and  successful  at  a 
personnel  activity  at  Lakehurst,  New  Jersey,  future  software 
enhancements  are  to  extend  the  variety  of  functions  to  mobi¬ 
lization,  order  delivery  ana  processing,  and  Reserve 
personnel  accounting  and  drill  reporting.  Plans  call  for 
CCMN A VP 2SF0R  to  develop  a  distributed  personnel,  pay,  and 
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training  system  by  the  second  quarter  of  Fiscal  Year  1936. 
Integration  testing  of  initial  Reserve  support  applications 
will  begin  in  FY  86.  Software  used  in  this  consolidation  of 
Active  and  Reserve  personnel  data  base  systems  is  to  be 
tested  in  FY  86.  In  January  1987,  SD5  and  COHN  AVRESFOF.  are 
to  update  the  implementation  strategy  and  plans  for  exporta¬ 
tion  to  field  sites.  [Ref,  4:  pp.  2-3  to  2-7] 

Nonetheless,  RTSS  is  not  going  to  disappear  soon.  The 
Five  Year  Defense  Plan  indicates  a  requirement  for  funding 
through  1991.  A  MAPTIS  budget  increase  of  $924,000  is  being 
requested  for  POH  87,  all  of  it  earmarked  for  the  three  RTSS 
systems.  Contractor  support,  software  conversion,  and 
BSC/VAX-730  hardware  are  requested  to  support  the  systems 
and  "migrate  programs  to  a  more  current  technology"  [Ref.  4: 
p.  3-60,3-61],  Code  461  in  New  Orleans  indicated  that  much 
of  the  software  conversion  was  expected  to  be  done  in-house 
once  the  new  equipment  arrived. 

One  area  missing  from  this  long-range  plan  involves 
training;  specifically,  training  for  the  Officer  corps.  In 
the  past  computer  training  has  been  aimed  at  the  enlisted 
person  who  will  be  operating  the  computers.  In  fact,  basic 
computing  skills  are  now  being  taught  at  enlisted  ' A  ' 
school.  This  is  not  sufficient  to  achieve  proper  utiliza¬ 
tion  of  information  systems.  It  is  the  officer  corps  who 
should  know  how  to  convert  the  vast  amount  of  data  into 
usable  information.  They  must  receive  a  larger  portion  Oi 
information  systems  training  in  future  years  in  order  to 
make  proper  use  of  current  technology  and  effectively  manage 
tne  Naval  Reserve  in  the  rest  of  tne  1990's  and  the  1990's. 

D.  C  UR  RENT  TECHNOLOGY 

It  is  no  wonder  that  the  Naval  Reserve  has  oeen  slow  to 
technological  change.  Only  since  the  latter  years  of  the 


enroll;  the  information  is  entered  directly  into  the 
Activities  table  without  considerin';;  the  student  data 
entit  y. 

2  .  Da ta  Duplication 

The  problem  of  data  duplication  is  illustrated  in 
Figure  4.3  .  The  table  shown  contains  information  about  a 
reservist’s  Social  Security  Number  and  his  Reserve  Unit 
(UIC ,  Long  Name,  Address,  Sity,  State,  Zip).  It  is  immedi¬ 
ately  cbvious  that  this  design  will  waste  a  large  amount  of 
storage.  The  same  information  is  stored  about  the  Reserve 
Unit  for  every  member  of  that  unit.  One  copy  of  each 
reserve  unit’s  address  is  sufficient.  Data  duplication 
occurs  because  information  about  two  data  entities 
(Reservist  and  Reserve  Unit)  is  stored  in  the  same  table. 

i - 1 
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Figure  4.3  Data  Duplication  (uncorrected) 
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information  in. 


The  deletion  anomaly  problem  can  be  easily  explained 
using  Figure  4.2  as  well.  If  the  student  with  SID  100  drops 
out  of  school  and  that  record  containing  his  activity  infor¬ 
mation  is  deleted,  we  lose  two  important  facts.  First,  that 
student  100  was  participating  in  skiing.  This  was  the 
intent  of  the  deletion  and  is  an  acceptable  loss.  We  also 
lose  the  fact  that  to  participate  in  skiing  it  costs  3200. 
This  an  unacceptable  loss  resulting  from  poor  database 
des ign. 
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[Ref.  16:  p-  287] 


Figure  4.2  Modification  Anomalies  (corrected) 

The  design  to  eliminate  the  modification  anomalies 
in  Figure  4.1  is  shown  in  Figure  4.2  .  Notice  that  we  have 
provided  a  means  for  storing  information  about  students  and 
activities  in le pendently  by  creating  two  separate  tables. 
If  student  100  is  deleted,  we  still  know  that  skiing  costs 
$2 00.  If  we  want  to  know  how  much  student  200  has  paid  for 
his  extra-curricular  activities,  two  look-ups  are  required. 
First  in  the  student  table  and  then  in  the  Activities  table. 
A  idit  ionally ,  if  volleyball  (fee  =  $45)  is  added  to  the 
activities  list,  we  don't  have  to  wait  for  a  student  to 


one  data  entity  without  first  adding  a  fact  acout  another. 
A  deletion  anomaly  occurs  when  facts  about  one  entity  are 
lost  when  a  fact  about  a  different  entity  is  deleted.  These 
two  anomalies  are  illustrated  in  Figure  4.  1  and  Figure  4.2 
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Figure  4.1  Modification  Anoaalies (uncorrected) 

Vie  have  chosen  a  very  common  example  to  explain  how 
these  modification  anomalies  occur  and  how  they  are  elimi¬ 
nated.  In  Figure  4.2  there  is  a  table  to  collect  informa¬ 
tion  on  students(by  Student  Identification  'lumber  -  SID), 
the  extra-curricular  activities  activities,  and  the  fee  for 
that  activity.  The  insertion  anomaly  problem  occurs  if  a 
new  activity,  such  as  volleynall  (costing  $45),  is  added  to 
the  list  of  extra-curricular  activities.  We  want  to  add 
this  tc  the  database.  However,  this  is  not  possible  until 
the  first  student  enrolls  in  volleyball  and  there  is  a  valid 
SID  to  enter  along  with  the  activity  and  fee.  Tms  is  unac¬ 
ceptable.  The  only  way  to  add  a  fact  about  one  data  entity 
(an  activity)  is  tc  first  add  a  fact  about  another  (a 
student).  [Ref.  16:  p.  287  ] 


B.  HORHAIIZED  FOBHS 


1 .  Modification  Anomalies 

The  design  of  the  records  for  the  Naval  Air  Reserve 
prototype  involved  the  transformation  of  approximately  600 
data  fields  of  the  old  sequential  file  system  into  a  rela¬ 
tional  database.  One  important  aspect  of  this  design 
process  is  the  elimination  of  modification  anomalies  and 
data  inconsistencies.  Modification  anomalies  occur  when 
changing  or  modifying  data  yields  unexpected  results. 
Additionally,  most  incidences  of  data  duplication  are  elimi¬ 
nated.  Data  normalization  is  the  method  of  accomplishing 
this.  Normal  forms  are  the  means  by  which  data  normaliza¬ 
tion  is  done. 

To  adequately  explain  how  we  arrived  at  the  proto¬ 
type  design  in  Appendix  A,  we  must  first  present  the  normal 
forms  in  database  theory.  He  used  five  principal  normal 
forms  [Ref.  15:  p.  120].  There  are  numerous  articles  on 
normalization  which  expand  on  the  five  normal  forms.  These 
include  domain  key/normal  form  (Fagin)  and  Boyce-Codd  normal 
form  [Ref.  16:  p.  288],  To  explain  the  normalized  forms,  we 
found  that  normal  forms  one  through  five  as  presented  by 
Kent  are  the  most  logical  and  understandable. 

Normalized  forms  provide  guidelines  to  the  database 
designer  that  eliminate  errors  and  data  inconsistencies  in 
the  final  design.  These  guidelines  are  in  the  form  of 
progressive  design  steps  that  methodically  transform  a 
collection  of  data  fields  into  a  database  free  of  modifica¬ 
tion  anomalies  and  data  inconsistencies.  Normalization  is  a 
stepwise  refinement  of  the  tables  of  a  database. 

The  culprits  in  database  design  are  modification 
anomalies  and  data  inconsistencies.  There  are  two  major 
types  of  modification  anoEdlies— insertion  and  deletion. 
Insertion  anomalies  occur  when  we  cannot  insert  a  fact  about 
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17.  THE  PHOTOTYPE 


A.  INTRODUCTION 

The  purpose  of  this  chapter  is  to  present  the  Naval  Air 
Reserve  Prototype,  the  assumptions  made,  the  issues  dealt 
with,  and  the  prototype  design.  There  are  numerous  append¬ 
ices  associated  with  this  chapter.  Each  appendix  is  a 
portion  of  the  database  design.  This  chapter  discusses  how 
we  designed  the  database  with  the  actual  worx  appearing  in 
the  respective  appendices. 

A  majority  of  this  chapter  wall  discuss  how  the  ORACLE 
database  management  system  was  used  to  implement  the  many 
attributes  of  an  effective  automated  information  system 
discussed  in  chapter  three.  It  is  important  to  note  that 
this  prototype  is  only  an  example  of  how  the  Naval  Air 
Reserve  car.  use  current  technology  to  implement  its  many 
disjoint  systems  'under  one  roof*.  We  will  attempt  to  show 
that  the  needs  of  the  Reserve  can  be  best  suited  with  a 
fourth  generation,  relational  database  system  irrespective 
of  the  specific  commercial  product  chosen.  The  importance 
of  this  prototype  is  in  the  structure  of  the  data  itself. 
This  will  not  vary  greatly  between  products.  Throughout 
this  chapter,  we  will  present  the  shortfalls  of  ORACLE  to 
facilitate  a  more  informed  decision  for  the  actual  system. 
Prior  to  presenting  ORACLE,  however,  a  discussion  of  data¬ 
base  design  and  tne  use  of  normalized  forms  is  necessary. 

The  computer  industry  nas  not  developed  one  set  of  terms 
to  define  its  vocabulary,  so  we  wild  attempt  to  use  the  same 
term  in  referring  to  a  concept  or  tiling. 


consistent  and  timely.  The  prototype  of  RTSS  we  have  devel¬ 
oped  can  serve  as  a  working  model  for  the  Naval  Reserve  to 
develop  an  independent  query  and  report  oriented  marageaent 
information  system  using  off-the-shelf  curren t- gener at  ion 
tecnnology . 
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Develop  a  prototype  with  only  basic  functions: 
input, inquire, report, format. 

Let  managers  and  analysts  play  with  it  to  determine 
user  needs. 

Add  those  functions  common  to  many  users  and  put  in 
operation. 

The  point  is  that  it  is  a  selected  database;  users  will 
want  different  functions  or  will  quickly  become  bored 
with  it.  If  it  can  be  kept  relatively  simple,  it  can  be 
changed  or  replaced  with  small  investment.  [Ref.  14:  p. 
9] 


The  Commerce  Department’s  situation  is  certainly  analo¬ 
gous  to  the  state  of  affairs  that  the  Reserves  finds  itself 
with  RTSS  and,  indeed,  virtually  all  of  its  Automated 
Information  Systems.  The  history  of  mistrust  of  current 
AISs  by  those  most  in  need  of  them  is  the  most  immediate 
indication  that  the  users,  not  just  the  designers,  need  to 
be  personally  and  dynamically  involved  in  the  process  to 
make  the  system  work.  As  to  the  use  of  microcomputers ,  the 
Navy's  contract  with  Zenith  Data  Systems  for  the  Z-100  and 
Z-150  (IBM— PC  compatible)  microcomputers  could  be  an  excel¬ 
lent  vehicle  for  integrating  modern  information  technology 
into  the  Reserves  ATS  strategy.  It  would  also  fit  iD  with 
the  CP-16  HAPTIS  Program  Strategy  as  cited  above.  In  fact, 
the  relational  database  product  we  use  in  our  prototype  is 
advertised  to  be  completely  downloadable  to  an  IBM-PC/XT, 
which  is  essentially  a  Z-150  with  a  10  megabyte  hard  disk. 

On  the  other  hand,  it  might  be  necessary  to  continue 
expanding  a  prototype  RTSS  system  to  the  point  where  it  is 
no  longer  simple,  or  perhaps  there  might  be  a  desire  to 
segment  the  database  into  an  ad  hoc  part  and  a  static  part. 
In  fact,  we  use  more  than  80  data  elements  in  our  prototype, 
and  discuss  more  than  the  basic  functions  mentioned. 

Our  point  is  that  the  fourth  generation  software  of 
today,  like  that  which  we  used  in  our  prototype,  is  a 
E2!iS£X!ii  tool  that  has  the  capabilities  to  be  molded  into 
user  oriented  results.  Available  information  is  more 


Experimenting  with  fourth  generation  languages  as  a 
productivity  tool  is  now  going  on  under  the  MAPTIS  strategy 
at  NK  PC-4  £Eef.  4:  p.1-16],  and  the  concept  of  prototyping 
is  receiving  more  attention  in  the  Federal  environment. 
Consider  a  December  1984  article  by  tne  Deputy  Commissioner 
of  the  Financial  Management  Service,  d.S.  Treasury  Dept,  Mr. 
Marcus  K.  Page.  In  it  he  commented  on  the  Dept  of 
Commerce's  approach  to  bringing  comparable  resource  data 
together  from  several  bureau-level  organizations.  Initially 
their  focus  was  on  rebuilding  the  various  different  systems 
to  produce  comparable  data.  They  moved  from  there  towards 
one  common  system  in  each  function  being  shared  in  the 
department.  Neither  approach  solved  their  data  incompar¬ 
ability  problem.  They  then  transitioned  to  what  they  termed 
a  data  "bridge",  in  which  a  selected  number  of  data  elements 
from  several  systems  were  combined  into  a  common  system. 
Developed  by  a  contractor  in  a  relatively  short  period  of 
time,  it  had  a  relatively  low  cost  compared  to  a  major 
rebuilding  effort.  Fhiie  not  without  its  problems,  the 
system  at  Commerce  has  been  considered  a  success.  The  key 
to  its  success  was  in  its  simple  consolidated  data.  For  an 
agency  building  a  selective  data  base,  Mr.  Page  offered  some 
sound  advice: 


The  real  value  of  the  selected  data  file  method  that 
Commerce  used  is  that  it  fills  a  gap  relatively  guicklv 
and  provides  a  common  body  of  knowledge  that  managers 
and  analysts  can  manipulate  by  downloading  sections  of 
the  file  to  microcomputers  using  Spreadsheet  software> 
and  report  generators. 

Virtually  every  new  agency  organized  out  of  predecessor 
agencies  has  gone  through  the  same  process  of  trying  to 
bring  together  a  consistent  data  file  of  selected' infor¬ 
mation  ,  from  the  various  bits  and  pieces.  The  difference 
today  is  that  the  tools  are  getting  better  to  support 
lata  base  creation. 
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Cne  relatively  new  method  of  developing  requirements 
analysis  is  by  prototyping  the  system  using  fourth  genera¬ 
tion  user  friendly  query  languages.  Prototyping,  as  in 
aircraft  development,  has  come  to  mean  an  example  which  is 
never  actually  used  in  service,  only  as  an  experimental 
model  to  display  or  sell  operating  charact er istics.  A  soft¬ 
ware  prototype,  however,  is  a  pilot  working  model  of  the 
real  system  which  does  not  have  to  be  discarded,  but  can  be 
built  on  or  changed  at  will.  In  contrast  to  the  traditional 
software  development  approach  which  goes  through  lengthy 
stages  of  requirements  analysis,  design,  development  and 
implementation  before  a  product  is  seen,  the  output  of  the 
prototyping  process  is  generally  a  mini-version  of  a  desired 
end  product  built  with  the  close  involvement  of  the  users. 
On  a  limited  scale,  the  user  can  see  what  the  system  can  do 
in  roughly  an  order  of  time  less  than  the  traditional 
process.  This  builder/user  team  has  little  difficulty 
understanding  their  own  output;  the}  can  simply  modify  those 
items  they  are  not  happy  with.  When  the  team  is  satisfied 
with  the  performance  of  the  prototype,  the  development 
process  continues  and  expands,  but  the  system  also  can  go 
into  use.  As  familiarity  with  the  system  grows,  the  users 
themselves  become  the  systems  developers. 

The  Naval  Reserve  can  benefit  from  prototyping  in 
several  ways.  The  specifications  that  result  are  more 
complete  because  the  Naval  Reserve  can  better  evaluate  the 
system  and  tailor  it  to  their  needs.  By  interfacing  with 
several  levels  of  Naval  Reserve  management  during  the  proto¬ 
type  design,  the  developer  can  deliver  a  result  that  is  more 
responsive  to  the  whole  organization.  The  strategic  plan¬ 
ners  can  easily  obtain  the  summary  information  they  need 
while  the  operational  and  supervisory  personnel  will  experi¬ 
ence  more  efficient  data  input,  maintenance,  and  output 
opera  ti  ons. 
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analysis  era  and  fell  prey  to  these  two  problems  (poor  docu¬ 
mentation  and  not  meeting  users'  needs). 

Requirements  analysis  can  be  accomplished  in  numerous 
ways.  The  traditional  approach  has  been  to  identify  the 
functions  to  be  accomplished,  decompose  these  functions  into 
elementary  units  and  provide  a  written  document  to  the  user 
explaining  what  the  system  will  accomplish.  We  found  no  real 
requirements  analysis  documentation  in  our  look  at 
ATSS/F.T5S,  and  considering  when  the  development  occurred, 
none  is  expected  to  exist. 
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success.  The  time  allocated  should  be  a  function  only  of 
what  a  reasonable  estimate  of  the  development  time  is  and 
not  linked  to  any  internal  or  external  politics  of  the 
organization.  Likewise,  the  money  allocated  should  be  suffi¬ 
cient  so  that  the  project  team  isn't  handicapped.  This  is 
the  ideal  situation  and  is  not  likely  to  occur  with  great 
frequency. 

A  situation  which  is  more  likely  to  occur  is  where  the 
development  team  finds  that  most  variables  and  resources 
have  been  dictated  by  the  organization.  These  decisions  to 
commit  resources  are  usually  driven  by  factors  not  relating 
to  the  software  project.  This  usually  involves  the  organiza¬ 
tion's  management  mandating  the  project  completion  date  or  a 
specific  strategy  that  leaves  but  a  few  options  open  to  the 
developers.  The  development  team  must  strive  to  produce  the 
same  result  despite  factors  that  threaten  to  detract  from 
the  overall  quality. 

P.egardless  of  the  environment  in  which  the  software 
development  takes  place,  it  is  the  analysis  and  definition 
of  the  system's  requirements  that  can  create  the  fundamental 
difficulty  for  the  software  development  team.  Requirements 
analysis  is  the  cornerstone  from  which  software  will  be 
built.  It  is  the  input  to  the  design  team's  effort  which  is 
then  delivered  to  the  programming  team  for  coding  (see 
"igure  3.1  )  .  The  effects  of  a  poor  or  non-existent 
requirements  analysis  are  far-reaching  and  devastating. 

The  requirements  analysis  methodology  evolved  in  the 
early  1970's  and  was  a  substantial  improvement  in  the 
previously  unstructured  development  process.  Software  prod¬ 
ucts  from  that  era  were  typically  without  documentation  and 
very  difficult  to  maintain.  In  many  cases,  the  product  did 
not  satisfy  the  needs  of  the  user  because  care  was  not  taken 
to  ensure  that  user  and  developer  were  in  agreement.  The 
software  for  RTSS  was  developed  prior  to  the  requirements 


To  extract  the  optimal  performance  from  a  state  of  the  art 
computer,  new  software  must  be  used.  The  1950's  software 
would  still  be  inefficient  on  the  new  computer  and  most  of 
the  new  hardware  benefits  would  be  lost.  This  was  most 
recently  illustrated  by  the  failure  of  NAVAIR  to  effectively 
interface  the  new  VAX  computer  with  the  old  RSTS/E  operating 
system  for  ATSS.  The  same  argument  applies  for  current 
technology  software  installed  on  the  old  computers.  Many  of 
the  benefits  of  the  new  software  would  be  lost.  There  must 
be  parallelism  in  the  ST5S  development  plan.  RTSS  develop¬ 
ment  must  not  follow  the  path  of  ATSS  if  the  VAX  upgrade  is 
implemented  in  1987. 


E.  SYSTEMS  DEVELOPMENT 

updating  or  rejuvenating  an  obsolete  computer  system, 
whether  large  or  small,  is  a  major  undertaking  that  must  be 
managed  by  personnel  trained  in  the  systems ■ analysis  disci¬ 
plines.  With  the  advent  of  the  latest  generation  of  computer 
hardware  that  offers  greater  capacity  and  speed  at  a  cheaper 
price,  the  selection  of  hardware  is  less  critical  to  the 
overall  success  of  the  system  development  process.  Hardware 
is  still  important.  The  size  and  complexity  of  the  opera¬ 
tions  being  automated  must  be  correctly  gauged  to  ensure 
that  appropriate  hardware  is  acquired.  But  since  there  is 
usually  less  risk  in  selecting  the  correct  hardware  compo¬ 
nents,  the  deterministic  aspect  of  the  system's  development 
will  be  its  software. 

The  software  development  personnel,  their  methodology, 
and  the  technology  they  use  are  critical  elements  in  the 
eventual  success  or  failure  of  the  system.  The  ideal  situ¬ 
ation  that  the  development  team  would  like  to  encounter  is 
where  the  time  and  money  allocated  for  development  is  suffi¬ 
cient  and  that  management  is  committed  to  the  project's 
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the  policies  and  procedures  of  the  organization  and  there  is 
considerable  risk  involved  with  this  change.  Second,  the 
large  initial  cash  outlays  involved  with  developing  and 
implementing  a  new  computer  system  can  cause  managers  to 
side-step  the  issue.  Finally,  there  is  a  good  deal  of  risk 
involved  with  using  a  new  technology  that  has  not  stood  the 
test  of  time.  The  traditional  approach  to  maintaining 
computing  systems  has  been  to  minimize  cost;  spending  as 
little  as  possible  maintaining  existing  systems  leaves  many 
resources  available  for  other  purposes  [Ref.  13:  p.  3-]- 

The  current  systems  will  be  replaced  only  after  they  have 
become  unmaintainable  and  too  costly. 

Correctly  applied,  current  technology  allows  Naval 
commanders  to  approach  their  designated  missions  with  infor¬ 
mation  that: 

a)  Has  been  collected  and  recorded  simply 

b)  Has  improved  accuracy 

c)  Has  been  speedily  reported,  collected  and  distributed 

d)  Leads  to  summaries  that  are  timely  and  to  the  point 

e)  Has  enabled  both  manpower  commitments  and  costs  to  be 
reduced  [Bef.  8:  p.  3] 

Rapid  progress  in  information  systems  technology  has 
provided  the  potential  for  major  advances  in  their  effec¬ 
tiveness.  3 ut  these  advances  are  neither  automatic  nor 
easily  attained.  A  key  ingredient  for  the  success  of 
current  information  systems  is  a  comprehensive  plan.  This 
brief  analysis  merely  frames  the  problems  that  face  the 
Naval  Reserve  and  RTSS.  The  problems  we  nave  addressed  have 
evolved  because  of  a  lack  of  strategic  planning  that 
includes  the  use  of  new  technology  in  planning  for  computer 
systems. 

The  new  technology  that  is  chosen  by  the  Naval  Reserve 
must  have  hardware  and  software  compatibility.  There  must  be 
parallel  progress  in  both  the  hardware  and  software  areas. 

4  1 


Carter  administration  has  the  strategic  value  of  a  modern 
Reserve  force  been  translated  into  meaningful  funding.  The 
Reserves  have  traditionally  p^ggy- backed  the  active  Navy's 
procedures  and  systems.  Computing  policies  and  equipments 
have  followed  suit,  including  the  tendency  to  be  several 
generations  behind. 

Our  research  found  an  eager  but  skeletal  ADP  staff  at 
Code  46  in  New  Orleans.  Recognizing  their  need  for  assis¬ 
tance  in  this  volatile  field,  they  immediately  acted  upon 
the  NAVRES  ADP  Study  recommendation  to  implement  an 
Information  Systems  Support  Unit  (ISSU)  composed  of  top- 
rated  SSIRES  ADP  professionals,  only  to  have  the  program 
recently  cancelled  in  the  political  and  fiscal  fight  of 
mobilization  vs.  non-mobilization  billets.  The  staff  made  a 
concerted  effort  in  late  1934  to  canvass  the  SELRES  field 
for  a  selective  group  of  qualified  and  experienced  profes¬ 
sionals  that  would  meet  regularly  in  support  of  CNAVRZS 
Information  System  plans  and  goals.  No  sooner  did  they  have 
the  unit  selected  (September)  when  authorization  was  lifted 
at  budget  control  levels  (November)  on  the  grounds  that  the 
unit  would  have  been  a  non-mobilization  unit. 

Whatever  the  reason,  this  unit  must  be  establisned.  To 
move  towards  implementation  of  an  AIS  without  the  guidance 
of  these  proven  ADP  professionals  would  be  a  grievous 
mistake.  The  ISSU  must  provide  the  plan  for  managing  the 
Reserve's  resources  through  automation.  The  only  way  to 
adequately  prepare  for  mobilization  in  the  future  is  to 
manage  today' s  resources  with  an  automated  information 
system. 

There  are  some  natural  inclinations  in  management's 
decision  whether  or  not  to  upgrade  technologies.  When  a 
computer  system  has  been  in  operation  for  a  long  period, 
management  is  reluctant  to  move  to  a  new  technology  for 
several  reasons.  First,  the  system  has  become  imbedded  in 
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shows  the  two  tables  that  are  recessary  to  eliminate  data 
duplication.  This  design  has  the  RUIC  field  in  both  tables 
to  act  as  a  cross-reference.  Eliminating  all  but  one  copy 
of  the  Reserve  Unit’s  address  significantly  improves  the 
performance  of  the  database. 


Reservist  Information 


r  i 

SSN  i 

|  RUIC 
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i  29604 

222222222  j 
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1  STONE  RD 

MIAMI 

FL  i 
_ i 

29456 

Figure  4.4  1  ta  Duplication  (corrected) 


3 .  First  N ormal  Form 

Re  have  identified  the  major  inherent  problems  in 
database  design.  There  are  others  that  occur  infrequently 
and  will  be  discussed  as  they  pertain  to  the  normal  forms. 
Each  of  the  normal  forms  will  now  be  explained  and  an 
example  from  our  prototype  design  will  be  used  to  illustrate 
these  concepts,  where  possible. 


First  normal  form  is  the  easiest  to  satisfy  because 
it  is  the  broadest.  A  relation  is  in  first  normal  form  if 
all  occurrences  of  that  record  type  contain  the  same  number 
of  data  fields  and  none  of  these  fields  contain  the  same 
type  of  information.  These  are  called  repeating  groups.  The 
data  elements  dictionary  for  RTSS  had  numerous  repeating 
groups.  This  is  not  acceptable  in  relational  theory.  For 
example,  the  data  field  Secondary  Navy  Enlisted 
Classification (S NEC)  was  allowed  to  repeat  in  one  record  for 
up  to  four  occurrences.  We  eliminated  this  first  normal 
form  violation  by  creating  the  table  shown  in  Figure  4.5 
Note  that  the  number  of  data  fields  is  only  two  and  that  all 
records  are  the  same  length.  Repeating  groups  are  elimi¬ 
nated  by  making  a  separate  record  for  each  SNEC.  The  proce¬ 
dure  shown  in  Figure  4.5  was  used  in  all  cases  where  we 
found  first  normal  form  violations  in  the  RTSS  data  elements 
dictionary. 

4 .  Second  and  Third  Nor ma 1  Form 

Second  and  third  normal  forms  are  usually  discussed 
together.  These  deal  with  the  relationship  between  the  key 
and  nonkey  data  fields.  A  key  is  one  or  more  data  fields 
that  uniquely  identifies  a  record.  A  nonkey  data  field  "must 
provide  a  fact  about  the  key,  the  whole  key,  and  nothing  but 
the  key"  [Ref.  15:  p.  120]. 

Second  normal  form  is  violated  when  a  nonkey  data 
field  is  a  fact  about  only  part  of  a  composite  key.  Figure 
4.6  shows  a  table  that  keeps  track  of  the  reserve  unit  and 
reserve  billet  sequence  code(RFSC)  relationship.  The 
address  of  the  Reserve  Unit  is  also  stored.  Data  duplica¬ 
tion  is  an  obvious  problem  with  this  design.  Second  (and 
third)  normal  form  eliminates  this  problem.  In  this  partic¬ 
ular  case,  the  reserve  unit's  address  is  a  fact  about  or.lv 
Reserve  Unit  and  not  about  RBSC.  Figure  4.7  shows  the 
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*  this  design  violates  first  normal  form 
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2813 

222222222 

2096 
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#  this  design  is  in  first  normal  form 


Figure  4.5  First  {formal  Form 

design  in  correct  second  normal  form.  All  of  the  nonkey 
data  fields  now  describe  the  whole  key  and  not  just  a  part 
of  it . 


Third  normal  form  is  violated  when  a  nonkey  data 
field  is  a  fact  about  another  nonkey  data  field.  This  is 
very  similar  to  second  normal  fora  and  is  resolved  in  the 
same  manner  as  shown  in  Figure  4.7  When  a  relation  is  in 
third  normal  form,  every  data  field  is  either  part  of  the 
key  or  provides  a  single  valued  fact  about  exactly  the  whole 
key  [Ref.  15:  p.  121]. 
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Figure  4.6  Second  Normal  Form  (un corrected) 
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12345 
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CITY  1  ST  |  ZIP 

1  1  _  _ 

23456 

206  J  ST 

TULSA  |  OK  |  45678 

1  i 

Figure  4.7  Second  Normal  Form  (corrected) 

5 •  Fourth  and  Filth  Nor ma 1  Forms 

Fourth  and  fifth  normal  forms  have  evolved  to  solve 
those  problems  involving  multivalued  facts.  Multivalued 
facts  correspond  to  many-to-m  any  and  many-to-one  relation- 
snips.  An  example  cf  these  two  relationships  is  shown  in 


Figure  4.8  .  Part  A  shows  that  a  student  may  be  enrolled  in 
more  than  one  class  and  each  class  may  have  more  than  one 
student.  This  a  many- to-many  relationship.  Part  B  shows 
that  a  father  may  have  more  than  one  child  but  that  a  child 
may  only  have  one  father (natural) .  This  is  a  many-to-one 
relationship. 

There  were  not  many  incidences  of  multivalued  facts 
in  the  Naval  Air  Reserve  prototype  design  so  we  will  not 
continue  with  a  discussion  of  fourth  and  fifth  normal  forms. 
In  designing  our  prototype,  we  accounted  for  the  few  multi¬ 
valued  facts  in  the  proper  manner. 

6 .  Tradeoffs 

The  result  of  a  fully  normalized  design  is  a  data¬ 
base  free  of  modification  anomalies  and  data  inconsisten¬ 
cies.  One  major  advantage  of  full  normalization  is 
minimizing  maintenance  problems  involved  with  a  continuously 
updated  database.  Fewer,  simpler  rules  exist  for  personnel 
who  update  information  in  the  database  when  design-related 
errors  have  been  eliminated.  The  computer  operators  can 
concentrate  their  efforts  on  entering  correct  data  into  the 
database. 

There  is  a  tradeoff  involved  with  this  ’superior' 
design.  A  performance  penalty  may  be  paid  for  a  fully 
normalized  design.  Retrieval  can  be  expensive,  since  data 
which  may  have  teen  retrieveable  from  one  record  in  an 
unnormaiized  design  may  have  to  be  retrieved  from  several 
records  in  a  normalized  form.  The  advantages  outweigh  this 
penalty  because  most  records  are  smaller  and  can  be  accessed 
individually  without  concern  for  the  physical  structure  of 
the  database.  [Ref.  15:  p.  120] 

The  proper  balance  between  a  fully  normalized  effec¬ 
tive  design,  and  a  less  normalized,  but  more  efficient 
design,  is  difficult  to  achieve.  The  correct  balance  for 
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B  Many-to-One 


Figure  4.8  Multivalued  Relationships 
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one  organization  may  be  different  for  another.  This  is  a 
function  of  the  way  the  organization  uses  the  database.  If 
retrievals  are  predominant,  a  design  that  contains  some 
well-placed  data  duplication  would  be  a  more  appropriate 
database  design.  In  the  case  of  the  Naval  Air  Reserve 
prototype,  a  small  amount  of  data  duplication  has  been 
allowed.  This  will  improve  efficiency  of  the  design  without 
permitting  any  modification  anomalies.  A  later  section  on 
improving  efficiency  using  ORACLE  features  will  explain  how 
greater  efficiency  was  achieved. 

Appendix  A,  the  data  elements  dictionary,  shows  the 
physical  structure  of  our  design.  This  design  contains  all 
of  the  data  entry  minimum  requirements  discussed  in 
COM N A 7A IRES FOR INST  1510.1  (of  29  August  1  984)“  with  the 
following  exceptions: 

a)  3SN/CURRENT 

b)  BSN/DATE  ASSIGNED 

c)  BSN/PREVIO'JS 

d)  3SN/DISTRIB0TZD 

e)  BSN/TRAINED 

f)  NEC/D 1ST RI BOTE  D 

g)  NEC/TRAINED 

This  design  is  the  first  iteration  of  the  prototype  design 
and  will  be  tested  by  the  end  users.  Secommenda tions  for 
changes  will  be  incorporated  into  later  versions  of  the 
pr ot  oty  pe. 

Throughout  the  rest  of  this  chapter,  we  will  use 
examples  from  the  prototype  to  illustrate  a  concept.  You 
should  refer  to  Appendix  A  frequently  so  that  the  figures 
are  meaningful. 


“CCMNA7AIRZSFOBI NST  1510.1  provides  policy  and  guidance 
for  the  utilization  of  the  Reserve  Training  Support  System 
for  Air  by  COM NA7AI5 ESFOR  commands. 
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C.  OEACLE  DATABASE  HAHAGEMENT  SYSTEM 
1 .  The  System 

Now  that  the  basics  of  database  design  theory  nave 
been  explained,  we  can  present  the  specifics  of  the  Naval 
Air  Reserve  prototype.  The  first  step  in  presenting  the 
prototype  is  to  introduce  the  database  management  system 
that  we  chose  to  implement  the  design  on.  Once  you  are 
familiar  with  the  features  of  ORACLE,  we  will  discuss  how 
they  were  used  to  incorporate  the  important  attributes  of  an 
effective  management  information  system  into  our  design. 

The  ORACLE  database  management  system  is  marketed  by 
Relational  Software,  Incorporated,5  of  Menlo  Park, 
California.  The  first  copy  of  ORACLE  was  installed  in  June 
1579.  Relational  Software  has  implemented  ORACLE  on  Digital 
Equipment  Corporation's  (DEC)  PDP  11/23  through  11/70  series 
processors  using  ESX-11M,  IAS,  and  UNIX  operating  systems 
and  the  VAX  1  1/780  under  VMS  and  UNIX.  Starting  in  1981, 
they  also  began  offering  versions  that  ran  on  International 
Business  Machines  (13  M)  Corporation's  360,  370,  43xx,  and 

303x  series  processors  under  VM/CMS  and  MVS  operating 
systems.  The  company  recently  announced  that  all  of  ORACLE, 
not  just  a  subset,  will  be  available  to  run  on  the  IBM  PC  XT 
and  PC  AT. 

2-  System  F  eatures 

ORACLE  provides  a  wide  range  of  features  which  are 
listed  nelow: 

a)  Fully  integrated  data  elements  dictionary. 

b)  Provisions  for  use  in  both  distributed  and  local/ 
central  environments. 


Relational  Software,  Inc.  has  since  changed  its  name  to 
ORACLE,  Inc. 


c)  Provides  fall  support  for  I3l1's  relational  language 
SQl(also  called  SEQOEL  2,  for  more  details  see  subsec¬ 
tion  4)  . 

d)  Fully  reentrant  code. 

e)  Multitask  processing. 

f)  Interactive  applications  generator. 

g)  Full  function  report  writing  facility  that  includes 
both  text  processing  and  procedural  language  options. 

h)  Operates  in  batch  and  on-line  (interactive)  environ¬ 
ments. 

i)  A  host  language  interface  and  precompiler  to  allow 
C 0301 ,  FORTRAN,  and  C  applications  programs  to  inter¬ 
face  with  SQL  and  the  database. 

j)  Data  communications  support  for  ail  DEC  equipment 
mentioned  earlier  and  for  IBM  360  and  370  systems. 

k)  Security  and  privacy  mechanisms  operating  at  the  data¬ 
base,  table,  record,  field,  field  value,  and  key 
levels. 

l)  Restart/recovery  options  which  are  automatically  trig¬ 
gered  when  failure  is  sensed. 

Many  of  these  features  were  used  in  our  application  and  will 
be  described  in  more  detail  in  the  appropriate  sections 
later  in  this  chapter. 

3 .  System  Com  ponen  ts 

ORACLE  can  be  divided  into  three  major  components: 
the  SQL  data  language,  a  data  elements  dictionary,  and  a 
kernel  (  see  Figure  4.9  ).  SQL  is  an  English- like,  high 
level  language  that  will  be  discussed  in  detail  in  subsec¬ 
tion  4. 

The  fully  integrated  data  elements  dictionary  is  a 
vecy  powerful  tool  for  us  as  database  designers  and  for  the 
Naval  Air  Reserve  as  the  eventual  end-users.  The  dictionary 
contains  table,  row,  and  column  definitions,  views  of  tables 


Figure  4.9  ORACLE  Component  Block  Diagram 

and  data  fields,  and  information  about  users  and  their  data 
access  privileges  [Ref.  17:  p.  Ill], 

The  table,  row,  and  column  definitions  are  assigned 
dynamically  when  they  are  created.  Any  modif ica tions  to  the 
database  are  automatically  entered  without  the  need  for  the 
designer  to  reorganize  the  database  or  recompile  the 
existing  programs  [Ref.  17:  p.  1 1 2  J.  The  dictionary  also 
keeps  track  of  the  views  of  all  tables,  who  created  the 
view,  and  who  has  access  to  it.  A  view  is  a  restriction 
placed  on  a  table  so  that  only  selected  columns  and  rows  are 
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the  data- 


visible  to  selected  individuals.  In  other  words, 
base  designer  can  specify  what  tables  a  user  can  see,  and 
within  those  tables,  what  columns  and  rows  that  user  can 
see.  This  feature  allows  information  to  be  hidden  from 
those  individuals  who  should  not  have  access  to  it.  All 
security  and  control  information  on  data  and  users  are  kept 
in  the  dictionary. 

The  third  component  of  ORACLE  is  the  kernel.  The 
kernel  allocates  resources  for  ORACLE  in  the  same  manner 
that  the  operating  system  allocates  resources  for  the 
computer  system.  The  following  paragraph,  [  Bef .  17:  p. 
113],  best  describes  the  kernel: 


The  kernel  automatically  reallocates  and  reuses  space 
from  a  central  storage  pool  to  optimize  the  physical 
location  of  related  data  items  within  the  database!  In 
addition,  the  kernel  dynamically  manages  all  ORACLE 
buffers,  using  an  LEO  {Last  Record  Update)  caching  algo- 
rithm^to  maximize  reuse  of  core-resident  information  The 
kernel  also  enables  ORACLE  to  support  multiple  concur¬ 
rent  batch  and  on-line  terminal  updates  and  queries  to 
the  database.  It  can  overlap  I/O  operations ^up  to  the 
limit  of  the  hardware  configurations. 


4.  SQL 


SQL  is  an  English- like  language  that  supports  five 
functions:  query,  data  definition,  data  manipulation,  data 
control,  and  host  language  coupling.  The  English-like  char¬ 
acteristics  of  SQL  are  ideal  for  non- pr oced ural  queries  of 
the  database.  The  user  describes  what  he/sne  wants  using 
English  terms,  such  as  shown  in  Figure  4.  10,  and  ORACLE 
formulates  a  procedure  to  find  the  desired  data.  [Ref.  18: 
p.  562] 


The  query  function  relies  on  'an  operation  called 
mapping  for  its  success.  Using  Figure  4. 10,  the  concept  of 
mapping  is  that  a  known  quantity  (EUIC  =  29604)  is  used  to 
find  a  desired  quantity  ( S3 N  and  Last  Marne)  from  a  relation 
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SELECT  SSN,  NAM  ELA  ST 
EHCM  NAME 

W  H  EF.E  R'JIC  =  2  S  6  0  4  ; 


j 


Figure  4. 10  Non-Procedural  Language 

or  table  (NAME).  The  three  basic  terms  used  for  queries  are 
SELECT,  FROM,  and  WHERE.  SELECT  is  used  to  declare  the 
desired  information,  FROM  gives  the  relation  (s)  to  be 
searched,  and  WHERE  provides  the  known  fact  that  must  be 
satisfied  by  the  desired  data.  Figure  4.11  provides  some 
basic  examples  of  the  guery  facility.  For  a  more  detailed 
discussion  of  SQL,  consult  references  17  and  13. 

The  data  definition  language  (DDL)  is  used  to  define 
tables,  rows,  columns,  views,  indices,  and  clusters  (indices 
ar.d  clusters  are  discussed  later  in  the  section  on  improving 
system  performance).  The  data  definition  language  facility 
is  primarily  a  tool  for  the  database  designer.  However, 
once  the  database  is  installed,  the  DDL  can  be  used  by  the 
user  to  adapt  the  system  to  meet  the  needs  of  the  dynamic 
environment  it  is  supporting.  This  facility  describes  the 
data  structure  that  will  be  used  by  the  other  features  of 
ORACLE.  A  data  structure  must  first  be  defined  with  DDL 
before  it  can  be  accessed  by  the  other  SQL  facilities. 
Figure  u . 1 2  illustrates  now  two  of  the  most  common  terms  are 
used.  The  two  examples  are  self-explanatory  since  they  are 
£r.  jlish-like.  The  number  in  parentheses  is  the  maximum 
number  of  spaces  that  a  particular  data  field  can  occupy. 
NOT  NULL  is  the  SQL  method  for  making  a  field  mandatory. 

The  data  manipulation  language  (DML)  allows  users  to 
change  the  value  of  data  stored  in  the  fatanase.  There  are 


*nree  operations  that  can  be  performed:  insertion,  deletion. 


Nested  tapping  — Find  the  SSN  and  Mane  of  all 
Reservists  in  the  Houston  area 


SELECT  SSN,  NAME LAST 
FROM  NAME 
WHERE  ROIC  IN 

SELECT  ROIC 

FROM  RESERVUNIT 

W HERE  CITY  =  ' HOUSTON  1  ; 


Count--How  many  different  PNZC's  are  there  at 
RUIC  29604? 


SELECT  COONT  (UNIQUE  PNEC) 
FROM  NAME 

WHERE  RUIC  =  29604; 


Joir.--a  join  operation  must  occur  when  a  query 
returns  results  from  more  than  one  table.  “  The 
:cin  oneration  is  implicit. 

What  are  the  SSN’s  and  RUIC's  of  all  reservist's 
saving  NEC  0612?  (NEC's  are  stored  in  two  tables- 
NAMc.  contains  the  PNSC's  and  N03C  SNEC  contains 
the  ENSC's) 


SELECT  NAME. SSN,  NAME. RUIC 
FROM  NAME,  NC3C  SNEC 
WHERE  N AM i. P NEC- =  '06  12' 

CR  N03C  SNEC. SNEC  =  '0612'; 


1 

Figure  4.11  ORACLE  Query  Function  i 


CREATE  TABLE  NAME 
(SSN  NUMBER.  (9)  NO!  NULL, 
NAMELAST  CHAF.  (20)  NOT  NULL, 
NA  MFF  CHAP.  (14))  ; 


Figure  4.12 


Data  Definition  Language 


and  update.  Figure  4.13  illustrates  how  these  are 

accomplished. 


1.  Insertion 

In  SERI  INTO  SPECIALIST 

SELECT  NAME. SSN,  NAME.  F.UIC 
FROM  NAME,  NCBC  SNEC 
WHERE  NAME. PNEC  =  0612 
OR  NO BC_  SNEC. SNEC  =  06  12; 

2.  Deletion 

DELETE  MOB  3ILLTS 
WHERE  AUIC_r  32314; 

3 .  Update 

UPDATE  NAME 

SET  PAYGRADE  =  *05'  DOR  =  850115 
WHERE  SSN  =  123456739; 


Figure  4.13  Data  Manipulation  Language 


An  insertion  is  used  to  to  insert  new  data  into  a 
table  or  to  extract  data  from  one  table  and  place  it  in 
another.  Example  1  in  Figure  4.13  illustrates  the  latter. 
In  this  case,  tne  SSN  and  Reserve  ore  for  any  Reservists  who 
have  a  NEC  of  0612  are  extracted  from  their  current  table 
and  placed  ir.  the  SPECIALIST  table.  The  data  extracted  from 
tne  original  table  now  exists  in  two  tables-- the  original 
‘■.able  it  was  extracted  from  and  the  new  SPECIALIST  table. 
Notice  that  this  example  is  a  query  operation  linked  with  an 
insertion.  ~Le  insertion  provides  a  location  for  tne 
results  of  tne  , aery  to  be  deposited. 


A  deletion  i 
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Indexing  can  also  be  used  to  ensure  that  a  column 
within  a  table  has  a  unique  value.  In  otner  words,  a  lata 
element  may  only  have  a  specific  value  assigned  to  it  once 
in  the  table.  The  primary  use  of  this  feature  in  our  proto¬ 
type  is  with  hue  data  element  ’SSN'.  We  created  a  unique 
index  so  that  a  person's  SSN  will  only  be  listed  once.  This 
eliminates  the  possibility  of  a  member’s  record  being 
entered  more  than  once.  If  this  were  to  occur,  the  data  in 
each  record  would  be  suspect.  Figure  4.  IS  is  an  example  of 
how  we  created  a  *  UNIQ'JZ ’  index  for  SSN  on  the  NAME  table. 
Appendix  D  contains  the  list  of  indices  used  in  the 
prototype. 


CREATE  UNIQUE  INDEX  SSN 
NAME  (SSN)  ; 

I 
I 

I _ 

Figure  4.  18  Indexing 

Creating  an  in  index  improves  performance  but  also 
increases  the  amount  of  data  stored  in  primary  memory. 
Additionally,  if  there  are  excessive  indexes,  each  time  a 
record  is  added  to  a  table  that  is  indexed,  ORACLE  updates 
each.  The  more  indexes  there  are,  the  more  work  ORACLE  i.as 
:o  lo  to  keep  them  current.  This  will  slow  down  the  entire 
■  y  s  t  <?  m .  [Ref.  19:  p  .  201] 

2 .  Cluster! ng 

Clustering  of  data  together  in  the  same  physical 
i  ace  is  a  way  of  guaranteeing  that  two  tailes  that  are 
f ten  joined  together  are  also  stored  together.  Clustering 
s  totally  transparent  to  all  gueri-'s  against  the  data. 

■■  1 
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t)  Consistency  checks — used  to  ensure  that  values  in 
certain  data  fields  are  valid  in  relation  to 
entries  in  ether  data  fields.  This  is  also  done 
within  one  record  or  between  records. 

f.  IMPROVING  SYSTEM  PERFORMANCE 

A  relational  database  system  can  be  inefficient  when 
data  from  very  large  tables  or  from  several  tables  is 
retrieved.  If  there  is  no  plan  for  storing  related  data, 
each  search  through  the  database  must  look  at  every  record. 
In  de  si gni ng  our  pro  tot  ype,  we  developed  a  plan  that  limits 
the  number  of  records  that  are  viewed  before  the  correct  one 
is  found.  This  is  done  in  ORACLE  with  indexing  and 
clustering. 

1  -  Indexing 

Indexing  is  used  to  quickly  locate  the  pages9  of  the 
database  that  contain  specific  records  of  a  table.  The 
r P A C L  E  index  is  the  same  as  the  index  in  the  back  of  a  text¬ 
book.  It  provides  a  means  of  finding  subjects  without 
looking  page  by  page  through  the  nook.  The  index  in  a  book 
is  organized  ir.  alphabetical  order  and  allows  you  to  find 
ail  incidences  of  the  desired  subject. 

The  indexing  system  of  ORACLE  uses  this  same  prin¬ 
ciple.  it  uses  its  indexes  to  locate  pages  or.  disk  that 
contain  the  desire  1  records.  This  is  an  excellent  way  to 
shorten  the  time  it  takes  to  execute  a  query.  The  index 
eliminates  the  need  to  search  the  entire  database  tc  locate 
t,.e  desire  1  record ;  only  the  page  where  the  record  resides 
must  be  searched. 


'’Database  pages  are  physical  areas  on  iisr.  storage 
devices  that  ho  ad  the  data  m  the  data  Las  e  like  r,i  a-  r  ,  a  ;en 
hoi  l  t  he  mforjidtioii  in  a  book.  [Ref.  19:  p.  1  9  7  j 
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0FACL2  does  not  have  the  ability  to  verify  that  data 
contains  a  prescribed  pattern.  For  example,  F3SC  has  a 
pattern  of  four  digits  and  then  a  letter.  Fie  can  not  check, 
that  this  pattern  is  adhered  to  at  input  time. 
Consequently,  R3SC  is  specified  as  character,  with  a  maximum 
of  five  spaces  in  the  data  elements  dictionary. 

3 .  Reasonableness  Checks 

The  final  check  is  a  reasonableness  checx.  After 
the  transaction  is  confirmed  as  valid  and  the  format  is 
correct,  we  must  check  to  see  if  tae  value  of  the  input  lata 
falls  within  reasonableness  constraints.  For  example,  for  a 
two-day  Weekend  Training (WET) ,  we  do  not  want  the  number  of 
drills  entered  to  be  greater  than  four.  Oracle  supports  the 
following  reasonableness  checks: 

1.  Field  Constraints  —  Each  of  these  three  are  accom¬ 
plished  in  ORACLE  with  the  Interactive  Applications 
Generator  mentioned  earlier. 

a)  Range- -checks  the  upper  and  lower  limits  of  the 
data  entry  to  ensure  they  are  with  in  acceptable 
bounds . 

b)  Compl eteness--used  to  ensure  that  mandatory  fields 
have  been  assi-jned  values  and  that  fields  with  a 
set  number  of  characters  nave  been  completely 
filled  in. 

c)  Cole-- used  to  verify  that  the  contents  of  a  data 
field  contain  a  code  that  is  authorised  ir.  a  list 
of  current  codes. 

2.  Interrecord/Intrarecor i — Each  of  these  are  also 
accomplished  with  the  Interactive  Applications 
Gene  ra  tor . 

<3)  Completeness  cuecks--usei  to  ensure  that  certain 
fields  are  filled  in  as  a  result  of  entries  into 
other  lata  fields.  This  occurs  wit.ain  a  recor  1 
and  between  records. 
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.Format  C  hec  ks 

Format  checks  ensure  that  the  data  to  be  entered 
conforms  to  certain  pre-defined  criteria  describing  the 
physical  structure  of  each  data  item.  OPACLE  accomplishes 
this  through  its  active  Data  Elements  Dictionary. 

The  data  elements  dictionary  for  our  prototype  is 
contained  at  Appendix  A.  It  lists  the  the  data  field  name, 
its  type  (number,  character,  or  date),  its  length  (this  is 
the  maximum  length  allowed),  and  whether  the  field  is  manda¬ 
tory.  Null  means  the  field  can  be  blank;  Not  Null  means  it 
must  be  filled.  A  field  may  be  of  type  ’character'  even  if 
it  contains  only  numerics.  The  choice  is  based  upon  whether 
arithmetic  will  be  performed  on  the  data  field.  Arithmetic 
operations  are  not  permitted  on  character  type  fields. 
[Ref.  21:  p.  8] 

The  data  elements  dictionary  wiil  perform  the 
following  format  checks  on  ail  data  input  transactions 
automat icaliv : 

a)  Length  checks--ensure  data  does  not  exceed  the  maximum 
prescribed  number  of  characters. 

b)  C haracter- type  checks--ensure  data  is  of  the 
prescribed  type. 

In  addition  to  the  data  elements  dictionary 
enforcing  prescribed  format,  our  prototype  has  a  series  of 
input  programs  that  contain  additional  format  cnecks.  These 
jiojraas,  created  with  the  Interactive  Applications 
Generator,  allows  the  input  operator  to  execute  a  "screen" 
that  aids  in  the  input  process.  Appendices  B  through  ? 
contain  a  picture  of  the  screens  and  the  interactive 
programs  that  create  them.  These  input  screens  enforce  the 
criteria  that  tnere  must  a  fixed  number  of  characters.8 

8For  example.  R  iJ  IC  wiil  aiwavs  contain  five  numbers.  SSN 
wil-i.  always  contain  nine  numbers,  and  STATE  will  always 
contain  two  characters. 
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feature  called  AUDIT  TRAIL  that  is  supposed  to  record 
certain  events.  The  designer  was  to  specify  what  events, 
such  as  unauthorized  access  attempts,  would  trigger  the 
audit  trail.  The  audit  trail  would  tnen  take  a  picture  of 
what  happened  and  who  attempted  it. 

After  a  futile  attempt  to  implement  this  feature,  we 
contacted  ORACLE,  INC.  and  were  told  that  the  feature  did 
not  work  and  was  no  longer  supported.  This  is  a  weakness  of 
some  significance,  but  not  fatal.  This  shortcoming  was 
partially  offset  by  procedures  designed  to  protect  the 
dat  abase. 

E.  DATA  INTEGRITY 

Data  integrity  involves  the  correctness  of  data.  The 
purpose  of  enforcing  data  integrity  rules  is  to  ensure  that 
correct  data  is  entered  into  the  database  and  that  it 
remains  correct  while  there.  The  technigues  to  enforce  lata 
integrity  are  transaction  validation,  format  checks,  and 
reasonableness  checks.  [Ref.  20:  p.  218].  We  will  discuss 
what  each  is  and  how  they  were  implemented  in  our  prototype 
using  ORACLE. 

1  •  l£fiii§3Ction  Validation 

A  transaction  validation  is  concerned  with  ensuring 
tha*-  an  input  or  modification  is  authorized.  This  was 
discussed  in  great  detail  in  the  Data  Security  section. 
ORACLE  enforces  this  with  the  privilege  facility.  Only 
transactions  authorized  by  the  owner  of  the  tanle  are 
allowed  (refer  to  Figure  4.16).  Proper  security  is  the 
first  ster  toward  sound  data  integrity. 
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CR  EA 


VIEW  CPS  AS 


SELECT  NAME  .  S5N,  NA  MELAST,  NA  M5F  ,  RA  NX  OR  E  ATE,  DO  R, 
CL  R  ACCESS,  A  DDE  ES  S  ,  C  I  T  Y,  S  TA  TE  ,  SI  ?  ,  HO  MEPH  CM 

FRCil  NAME,  R  'JI  C_  3  I L  LET  S 

WHERE  R'JIC- BILLETS.  DEPT='DPS'  ; 


Figure  4.  17  Alternative  7iew  of  Data 

listed  in  the  two  SELECT  lines  are  gathered  for  the  individ¬ 
uals  whose  SSIi's  were  collected  froa  R'J  IC_3ILL  ETS .  This 
information  is  the  subset  called  the  CPS  view.  The  view 
does  not  physically  contain  any  data,  so  creating  a  view 
does  not  mean  storing  the  same  data  twice.  This  would  be 
very  inefficient  and  present  some  difficult  data  maintenance 
problems. 7 

The  procedure  in  Figure  4.17  should  be  repeated  for 
each  department.  The  view  is  created  with  tne  department 
head  as  the  owner  and  controller  of  all  privileges.  The 
department  head  "'an  look  at  the  entire  NAME  table  (by  using 
the  SELECT  option  shown  in  Figure  4.16)  tut  can  only  manipu¬ 
late  the  data  in  the  OPS  view  of  NAME.  This  arrangement 
allows  the  command  to  maintain  control  of  the  entire  data¬ 
base  and  gives  the  department  head  freedom  to  manipulate  his 
subset  of  the  database. 

Now  that  we  nave  described  how  this  prototype 
protects  the  data  from  unauthorized  access  on  several 
levels,  we  must  briefly  discuss  now  an  unauthorized  access 
attempt  car.  be  detected.  The  latest,  version  of  ORACLE  has  a 

7Storir.g  the  lata  twice  about  tue  same  person  would  mean 
that  if  the  'lata  was  changed,  it  would  have  to  be  updated  in 
two  places.  "he  overhead  reguired  to  lo  this  would  render 
views  useless.  This  does  not  occur. 
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GRANTOR  GRANTEE  CREATOR  T  NAME 


TIMESTAMP  A  D  I  S  U 


1.  UPPER  LEVEL 

WINSLOW  WINSLOW  WINSLOW  NAME  29-NOV-34  G  G  G 
WINSLOW  WINSLOW  WINSLOW  LANGUAGE  Q4-DEC-84  G  G  G 
WINSLOW  WINSLOW  WINSLOW  EDUCATION  05-DEC-34  G  G  G 
WINSLCK  WINSLOW  WINSLOW  RESERVUNIT  20- DEC-34  G  G  G 
WINSLOW  WINSLOW  WINSLOW  MOB  BILLTS  20-DEC-84  G  G  G 
WINSLCW  WINSLOW  WINSLOW  CLEARANCE  20-DEC-34  G  G  G 
WINSLOW  WINSLOW  WINSLOW  NOBC  SNEC  16- JAN-35  G  G  G 
WINSLOW  WINSLOW  WINSLOW  EUIC“BILLET  16-JAN-85  G  G  G 
WINSLOW  WINSLOW  WINSLOW  MOBILIZE  16- JAN-85  G  G  3 
WINSLOW  WINSLOW  WINSLOW  DRILLS  16-JAN-85  G  G  G 
WINSLCW  WINSLOW  WINSLOW  ACDUTRA  23- JAN-35  G  G  G 


2.  MIDDLE  LEVEL 

WINSLOW  SEEGER  WINSLOW  NAME  30-JAN-85  Y 
WINSLCW  SEEGER  WINSLOW  RUIC  BILLET  04-FEB-35  Y 
WINSLOW  SEEGER  WINSLOW  EDUCATION  05-DEC-34  Y 
WINSLCW  SEEGER  WINSLOW  LANGUAGE  05-DEC-34  Y 
WINSLOW  SEEGER  WINSLOW  DRILLS  16-JAN-85  Y 
WINSLCW  SEEGER  WINSLOW  CLEARANCE  20-DEC-34  Y 
WINSLOW  SEEGER  WINSLOW  NOBC  SNEC  16- JAN-e5  Y 
WINSLCW  SEEGER  WINSLOW  ACDUTRA  23-JAN-85  Y 
WINSLOW  SEEGER  WINSLOW  RESERVUNIT  20-DEC-84  Y 
WINSLCW  SEEGER  WINSLOW  MOB  EILLTS  20-DZC-84  Y 


3.  LOWER  LEVEL 


SEEGER 

KURTH 

57  IN  SLOW 
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Alter  (the  current  record  structure) 

Delete  (a  current  record) 

Insert  (a  new  record) 

Select  (a  current  record) 

Update  (current  data) 

Grant  (has  the  privilege  and  can  grant  to  others) 
Yes  (has  the  privilege) 


Figure  4.  16 


Three-level  Privilege  Structure 


CD  CD  C  i  CD  CD  C D  CD  C  l  CD  (D  CD 


privileges  on  all  tables  and  the  authority  to  grant  those 
privileges  to  others. 

The  middle  level  shows  the  set-up  for  middle  level 
managers,  such  as  a  department  head.  Note  that  Seeger 
(acting  as  Operations  department  head)  has  less  privileges 
than  the  upper  level.  Additionally,  he  has  only  limited 
authority  to  grant  privileges  to  others. 

The  lower  level  of  privilege  options  is  for  those 
individuals  who  perform  record  input  and  update.  These 
individuals  have  update  and  insert  must  receive  their  privi¬ 
leges  from  an  authorized  user  in  the  upper  two  tiers  of  the 
privilege  scheme.  This  ensures  privileges  are  controlled 
at  a  high  level  and  that  managers  know  who  have  access  to 
the  data  in  the  database. 

Note  that  only  the  upper  level  has  the  delete  privi¬ 
lege.  This  privilege  is  reserved  for  this  level  because  we 
are  not  allowing  any  deletions  in  our  database  prototype. 
If  a  record  is  to  be  deleted,  the  input  operator  marks  the 
record  for  deletion  and  the  person  holding  DBA  privileges 
will  periodically  move  the  deleted  records  to  a  history 
file. 

The  security  mechanism  for  records,  data  fields,  and 
data  field  values  is  the  view.  A  view  is  a  logical  parti¬ 
tioning  of  data  so  that  the  user  only  sees  a  subset  of  the 
table  (or  tables) .  A  view  is  like  a  window  in  a  building. 
It  allows  people  to  look  at  only  a  certain  portion  of  what's 
inside.  When  a  view  is  created  it  allows  specified  people 
to  see  portions  of  the  database. 

Figure  4.17  shows  how  a  view  was  created  for  the 
prototype.  This  view  allows  the  Operations  department  head 
to  see  only  the  Operations  department  subset  of  the  table 
"NAME."  This  view  requires  gathering  information  from  two 
tables.  First,  all  SSN ' s  from  the  RUIC_BI LLETS  table  with  a 
Department  of  'OPS'  are  chosen.  Then,  all  the  data  fields 
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that  logically  restrict  the  data  that  a  user  can  see.  We 
will  discuss  each  of  these  methods  in  the  following  para¬ 
graphs,  using  examples  from  the  prototype. 

The  use  of  privileges  to  control  access 


To  review, 
revoked)  by 


wa  s 
th  e 
the 


mentioned  briefly  in  an  earlier  section, 
following  privileges  can  be  granted  (or 
owner  of  a  table: 

a)  SELECT 

b)  INSERT 

c)  UPDATE 

d)  DELETE 

e)  ALTER 

f)  INDEX 

g)  CLUSTER 

When  a  user  attempts  to  manipulate  the  data  in  a 
table,  ORACLE  will  first  verify  that  the  operation  has  been 
authorized  by  the  owner  of  the  table.  If  that  particular 
privilege  has  not  been  granted,  ORACLE  will  not  allow  the 
operation  and  generate  an  error  message  saying  that  the 
table  does  not  exist.  In  other  words,  if  an  unauthorized 
operation  is  attempted  by  a  user,  ORACLE  will  mask  the  table 
as  if  it  does  not  exist.  The  table  is  blocked  by  the  system 
from  unauthorized  access. 

It  is  the  responsibility  of  the  owner  of  the  table 
to  carefully  grant  privileges  to  selected  users.  Each 
users’  needs  must  be  analyzed  on  a  case  oasis.  Each  privi¬ 
lege  granted  must  be  justified  before  it  is  granted. 
Granting  of  privileges  must  be  closely  tied  to  job  require¬ 
ments.  Figure  4.16  shows  three  levels  of  privilege  options. 

The  upper  level  is  for  the  database  administrator. 
In  the  prototype,  Winslow  serves  as  the  DBA6  and  has  all 


6  In  actualit/.  the  DBA  has  more 
shown.  This  prototype  was  designed 
the  Computer  Science  VAX  11/780  and  a 
member  retained  full  DBA  orivileges. 


privileges  than  those 
on  ORACLE  installed  on 
computer  science  staff 
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Winslow  now  has  access  to  all  application  programs 
and  facilities  tnat  are  available  to  the  user  under  the  VMS 
operating  system.  He  chose  ORACLE  in  our  example  ana  typed 
"ORACLE"  next  to  the  prompt.  The  "J"  appears  as  a 

prompt  at  ail  times  when  you  are  in  the  7MS  environment. 
Winslow  then  types  "UFI"  (for  Oser  Friendly  Interface)  to 
enter  that  particular  facility.  UFI  is  the  primary  means 
that  a  database  designer  or  user  talks  to  ORACLE  using  the 
Lata  Definition,  Data  Manipulation,  and  Data  Control 
languages. 

ORACLE  requires  the  user  to  log  on  again  so  that  it 
can  check  its  own  list  of  access  privileges  for  proper 
authorization.  This  is  a  two-tiered  process.  First,  the 
username/passvor d  combination  is  checked  for  access  to  the 
database  itself.  An  authorization  failure  will  result  in 
tne  user  being  asked  to  log  on  again  (in  case  the  user  typed 
the  information  incorrectly) .  ORACLE  will  tolerate  two  such 
failures  and  will  exit  to  V  MS  if  a  third  occurs.  If 
successful,  the  message  shown  in  Figure  4.15  will  appear, 
followed  by  the  "UFI>"  prompt.  We  show  how  to  enter  the  UFI 
facility,  but  the  leg  on  procedure  for  all  of  the  ORACLE 
facilities  is  the  same. 

4  -  Data  Access 

The  second  tier  of  user  a utn orization  cross- 
references  the  username  against  a  table  that  records  who 
owns  what  tables  and  who  has  been  granted  privileges  on 
those  tables.  This  is  an  extremely  powerful  feature  of 
ORACLE  that  provides  a  high  level  of  security  on  the  data 
resident  in  the  database. 

This  security  mechanism  operates  at  the  table, 
record,  data  field,  and  data  field  value  level.  It  works 
using  two  different  methods;  through  the  control  of  privi¬ 
leges  granted  on  a  table  and  through  the  creat ion  of  views 
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on1  to  the  VMS  operating  system  and  ORACLE  database  manage¬ 
ment  is  shown  in  Figure  4.15  .  The  user  must  type  in  his 
name  and  then  his  password  next  to  the  appropriate  prompts. 
This  action  places  the  user  in  the  operating  system  environ¬ 
ment.  In  this  case,  Winslow  has  successfully  logged  on  to 
the  VAX  11/780  computer  and  the  VMS  operating  system.  Note 
that  a  string  of  X's  appear  where  the  password  is  typed. 
This  is  an  additional  security  feature  that  hides  your  pass¬ 
word  from  anyone  looking  at  your  screen.  In  most  cases,  the 
password  would  be  invisible,  but  we  show  'xxxxxx'  to  indi¬ 
cate  a  masked  password. 


You  are  connected  to  VAX/VMS  11/730. 

ENTER  USERNAME:  WINSLOW 
ENTER  PASSWORD:  xxxxxx 

Welcome  to  the  C.S.  Department's  VMS  3.7  system. 

Current  Software  Versions:  VMS  3.7  FORTRAN  3.5 

PASCAL  2. 5  ORACLE  4.0 

3  ORACLE 
$  DFI 

ORACLE  Utilities,  Copyright  (c)  1 97 3 ,  1  980 , 1 9  8 1  ,  1  982  ,ESI 

UFI  version  3.5  -  on  Tue  Jan  29  13:46:24  1935 

Connecting  to:  ORACLE  V4.0.12  -  Production 

ENTER  USERNAME:  WINSLOW 

ENTER  PASSWORD:  xxxxxx 

UFI>exit 

Logged  off  from  ORACLE. 


Figure  4.15 


User  Authori zation  (Log  on)  Procedures 


protected  from  unauthorized  users  and  the  data  must 
logically  partitioned  so  that  only  those  users  who  h 
access  to  the  database  and  the  need  to  Know  are  authori 
to  see  specific  data. 

2  -  Navy  AD?  Sec urity  Program 

OPNAVI NST  5239.  1A  (DON  ADP  Security  Manual)  regui 
a  combination  of  hardware,  software,  and  administrat 
procedures  to  protect  data  from  unauthorized  disclosu 
modification,  or  destruction.  Adequate  protection  is  a 
required  when  the  system  is  distributed  or  allows  multi 
users.  RTSS  is  such  a  system  and  ORACLE  accommodates  t 
requirement  with  a  lock  out  feature  that  will  not  alio 
user  to  access  a  record  that  is  being  used  by  another  us 
This  eliminates  the  problem  of  two  users  changing  the  s 
data  and  only  the  last  of  two  being  recorded.  With  1 


out , 

each  user  sees 

the  current  data  in 

turn  and 

knows  w 

he  is 

changing . 

This  instruction  also 

calls  for 

an  audit 

trai  1 

cases 

where  the  data 

is  of  a 

sensi ti ve 

na  ture. 

As  will 

discussed  later,  the  ORACLE  audit  trail  feature  is 
supported.  With  this  exception,  ORACLE  can  comply  w 
these  PCN  guidelines  for  ADP  security. 

3.  Database  Access 

The  first  barrier  for  stopping  unauthorized  acc 
is  the  computer  center  door.  Physically  limiting  the  peo 
who  enter  the  terminal  room  can  help  stop  some  unauthori 
accesses.  However,  if  the  size  of  the  organization  or 
number  of  users  is  large,  this  can  be  a  time-consumi 
expensive,  and  ineffective  method  of  enforcing  acc 
limit  s. 

The  most  common  method  of  access  authorizat 
involves  using  a  password  scheme.  The  process  of  ’logg 
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SPANT  SELECT,  INSERT,  UPDATE 
ON  NAME 
TO  ADAMS 

WITH  GRANT  OPTION; 


Figure  4-14  Data  Control  Language 

The  final  function  of  SQL  is  the  host  language 
interface.  The  host  language  interface  allows  SQL  state¬ 
ments  to  be  included  in  FORTRAN,  C030L,  and  C  programs.  A 
precompiler  (part  of  the  ORACLE  package)  intercepts  these 
statements  and  converts  them  into  valid  statements  of  the 
host  language.  The  host  language  interface  and  precompiler 
may  be  used  with  a  main  menu  to  make  entry  into  ORACLE'S 
facilities  easier  and  more  user-friendly. 

D.  DATA  SECDRIT Y 

1 .  Unauthorized  Access 

The  Naval  Air  Peserve  prototype  must  have  the  appro¬ 
priate  security  measures  built  in  to  minimize  the  risk  of 
unauthorized  users  viewing,  modifying,  inserting,  or 
deleting  data.  There  must  be  security  provided  to  protect 
against  unauthorized  access  from  both  local  and  remote 
sites.  The  remote  site  considerations  involve  securing 
communication  links  and  transmission  lines  in  a  manner 
appropriate  for  the  information  that  can  be  accessed.  We 
will  not  address  this  aspect  of  security  as  it  is  beyond  the 
scope  of  this  thesis.  Additionally,  we  will  not  address  the 
area  of  physical  security  of  the  computer  installation. 

Protecting  the  database  and  the  data  are  two 
distinct  issues  we  will  deal 
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with. 


The  database  must  be 


An  update  is  used  to  change  the  value  of  one  or  aore 
data  fields  in  either  single  or  multiple  rows.  Example  3  of 
Figure  4.13  shows  how  to  record  tne  promotion  of  the  member 
with  S3 N  123456789  to  Commander  (paygrade  05)  and  his  Date 
of  Rank  to  15  January  1985. 

The  fourth  function  of  SQL  is  data  control.  The 
data  control  language  (DCL)  enables  the  user  to  specify  who 
will  have  access  to  his/her  data  and  to  enforce  data  integ¬ 
rity  constraints.  The  phrase  'their  data'  implies  ownership 
by  the  user.  In  fact,  this  is  the  case.  The  person  who 
creates  a  table,  'owns'  it  and  has  the  authority  (and 
responsibility )  to  designate  who  else  can  interface  with 
that  table  and  its  stored  data.  The  following  privileges, 
[Ref.  19:  p.  182],  can  be  granted  by  the  owner  of  a  table: 

a)  SEIECT — data  in  your  table. 

b)  INSERT — rows  in  your  table. 

c)  UPDATE — columns  in  your  table. 

d)  DE1STE — rows  from  your  table. 

e)  ALTER  —  the  number  of  columns  in  your  table  or  the 
characteristics  of  a  column. 

f)  INDEX — create  an  index  on  a  column  of  your  table. 

g)  CLPSTSR--your  table  with  other  tables. 

The  owner  of  the  table  has  the  authority  to  grant  or 
revoke  any  or  all  of  these  privileges.  The  owner  can  also 
grant  privileges  to  all  users  by  using  the  term  PUELIC. 
Additionally,  if  the  owner  specifies  GRANT  OPTION  when  he 
grants  privileges,  the  recipient  of  the  privilege  can  grant 
that  privilege  to  ethers.  A  example  of  data  control 
language  is  shown  in  Figure  4.  14  . 

The  use  of  the  data  control  facility  to  enforce  data 
integrity  is  essential  to  the  development  of  a  database 
maintenance  policy.  This  is  discussed  in  detail  in  the 
section  on  data  integrity. 


liTil 


This  is  a  way  of  shortening  the  time  ^c3uired  to  join  the 
data  of  two  tables  responding  to  a  user-generated 

query.  [Ref-  22:  p.  25] 

Figure  4.19  shows  how  we  created  a  cluster  to  store 
the  two  tables  together  where  'F.'JIC*  for  each  is  the  same. 
The  cluster  is  created  first,  then  each  table  is  added  to 
it.  Notice  that  it  is  a  three  step  process. 


All  records  from  these  two  tables  where  the  'RUIC* 
is  the  same  will  be  stored  together  so  that  retrieval  will 
be  faster.  These  two  tables  were  clustered  because  the 
queries  that  will  be  routinely  generated  will  involve  data 
about  tne  P.UIT  that  is  contained  in  both  tables.  A  cluster 
is  more  efficient  than  an  index  m  this  case  because  only 
one  search  must  be  accomplished  to  :md  the  data  in  two 
tables.  An  index  would  only  locate  tne  page  that  the 
records  are  on  in  two  different  tables  an i  then  each  would 


have  to  be  searched. 


G.  E  ECO VEE  Y 

There  is  a  degree  of  risk  involved  with  storing  informa¬ 
tion  about  an  organization  in  a  computer.  Computers  stop 
unexpectedly,  disk  heads  crash,  operators  drop  disks, 
programs  have  tugs,  people  input  incorrect  data,  and  proce¬ 
dures  are  ignored  [  Bef .  16:  p.  4  15].  These  occurrences 

(called  media  failures)  can  not  be  allowed  to  stop  or  slow 
down  the  organization.  The  data  must  be  recons tr uct ed  to 
its  original  state.  The  most  common  way  to  ensure  that  the 
database  can  be  reconstructed  when  some  catastrophic  event 
occurs  is  a  recovery  scheme. 

1 .  Af ter  Image  Journal 

The  scheme  CF.ACLE  uses  is  roll  forward  recovery. 
ORACLE  uses  an  AFTER  IHAGE  JOURNAL  to  implement  this  roll 
forward  scheme.  Recovery  is  made  possible  by  keeping  a 
separate  parallel  journal  of  each  transaction  written  to  the 
database.  A  physical  record  of  all  changes  to  the  database 
is  produced  and  this  can  be  used  to  reconstruct  from  the 
point  where  the  loss  occurs.  After  Image  Journaling  is 
completely  transparent  to  the  user.  [Ref.  22:  p.  26] 

The  procedure  is  as  follows: 

1.  ORACLE  records  each  event  that  modifies  the  database 
and  places  it  into  a  file. 

2.  then  the  journal  grows  to  a  certain  size  or  after  a 
specified  period  of  time,  the  files  are  copied  from 
disk  to  tape. 

A.  Each  file  is  given  a  sequential  number  to  establish 
the  correct  order  of  each  occurrence. 

4.  when  a  media  failure  occurs,  the  last  copy  of  the 
database  known  to  be  good  is  retrieved.  T.ie  first 
After  Image  Journal  that  was  created  after  this  good 
copy  of  the  database  is  then  applied.  All  After 
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Image  Journals  that  were  created  after  this  first  one 
are  then  applied  in  order  until  the  database  is 
completely  reccnstruc ted. 

An  effective  recovery  scheme  using  proven  software 
and  rehearsed  procedures  is  essential  to  the  operation  of  an 
organization  that  maintains  its  files  on  a  computer  system. 
The  roll  forward  recovery  technique  that  is  implemented  in 
CRACLE  is  an  effective  method.  The  After  Image  Journals 
that  are  created  provide  a  fairly  low-risk  means  of  ensuring 
that  database  integrity  can  be  maintained,  even  in  the  event 
of  media  failure.  The  key  to  effective  recovery  is  in  the 
procedures  established  by  the  computer  center  management. 
These  procedures  must  be  practiced  prior  to  a  media  failure 
so  that  when  one  does  occur,  its  impact  is  minimal. 

H.  REPORT  WRITING 

A  modern  database  management  system  must  have  the  facil¬ 
ities  to  process  reports  for  the  organization.  It  must  be 
able  to  deal  with  straight  text  and  a  combination  of  text 
and  database  query  results.  This  feature  can  relieve  an 
organization  of  much  of  its  old,  outdated  programs  that 
extract  data  from  many  sources  and  presents  them  in  report 
format.  Because  the  data  is  consolidated  in  one  database, 
these  reports  are  usually  easier  to  write  anl,  more  impor¬ 
tantly,  easier  to  maintain. 

ORACLE  has  a  facility  for  text  formatting  and  report 
writing  that  is  capable  of  database  retrieval.  There  is  an 
interactive  feature  that  allows  inputting  a  value  for  a 
variable  before  the  data  is  retrieved  and  formatted.  This 
is  particularly  useful  when  a  report  is  being  prepared  for  a 
Reserve  Unit  and  the  computer  operator  supplies  the  RCIC 
before  the  data  is  retrieved,.  It  can  also  be  used  for  a 
document  for  an  individual  reservist  by  supplying  their  SSN. 
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n  each  report  we  attempted,  we  discovered  an  appar 
in  the  ORACLE  software.  This  problem  has  been  enco 
by  all  those  we  know  who  have  tried  the  report  writ 
ity.  This  is  not.  to  say  the  data  can  not  be  access 
he  query  facility  in  the  User  Friendly  Interface 
modate  short,  simple  reports.  But  the  problem  i 
obstacle  in  ORACLE'S  consideration  as  an  integra 
ase  management  system  for  the  Naval  Reserve. 
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I.  ORACLE'S  GRADE 

ORACLE  is  a  relational  database  management  system  that 
provides  a  fairly  easy  means  of  developing  a  database  proto¬ 
type.  Its  active  data  elements  dictionary  is  an  excellent 
feature  that  aided  us  as  designers  and  gave  us  a  large 
degree  of  flexibility  when  changes  were  required. 

ORACLE  has  the  necessary  security,  lata  integrity,  and 
performance  enhancement  features  to  sa ti sf v  this  application 
for  the  Naval  Reserve.  In  general,  the  features  listed  on 
pages  59  and  60  make  this  system  a  desireable  product. 
However,  the  proDlems  noted  with  the  report  writer  feature 
are  critical  in  the  choice  of  a  software  system.  If  the 
support  for  this  feature  is  improved  and  the  problems  are 
corrected,  then  this  product  would  De  a  good  choice  for  the 
Naval  Reserve.  A  caution-- this  thesis  did  not  set  out  to 
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evaluate  the  software  market  for  database  systems.  In 
critiquing  0.EACL3,  we  are  not  comparing  it  to  other  systems 
for  performance  or  price.  That  analysis  must  be  completed 
before  an  informed  selection  can  be  made. 
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V.  COSC LOSIONS  AND  RECOMMENDATIONS 

A.  CONCIO  SIOHS 

After  eight  years  of  planning  and  implemer.tat  ion 
efforts,  RTSS  is  not  getting  the  job  ione.  "h  outlook  lor 
a  new  contractor  to  effect  a  major  breakt  hro  j  ji.  or.  a  system 
that  uses  old  hardware  and  ancient  (dv  today's  standar  is) 
software  is  grim.  The  Navy  tried  to  upgrade  just  the 
training  software  and  failed-  Substantial  progress  towards 
the  goal  of  an  integrated  training  and  mobilization  database 
for  the  Reserves  cannot  occur  using  the  present  technology. 

At  CNAVRES ,  manual  intervention  is  still  a  must  in  order 
to  obtain  training  and  mobilization  data.  RTSS  (Air) 
remains  linked  to  a  fourteen  year  old  ATSS  system  whose 
software  still  cannot  transfer  records  from  one  site  to 
another.  Software  updates  are  late,  insufficient,  or  non¬ 
existent.  The  functional  sponsorship  for  the  entire  system 
lies  elsewhere.  RTSS  (TM)  is  dependent  on  an  IMAPMIS  AIS 
that  is  in  need  of  extensive  revision,  again  oy  a  functional 
sponsorship  outside  the  Reserves.10  The  RTSS  systems  are 
redundant  and  poorly  designed.  Progress  since  inception  of 
the  systems  has  been  glacial. 

The  skeletal  staff  at  Code  46  is  determined  but  help¬ 
less.  Overwhelmed  with  milestone  management,  they  lack  the 
time  and  budgetary  control  for  effective  AIS  strategic  plan¬ 
ning.  They  recognize  the  need  for  redesign  of  the  software 
away  from  the  current  system  and  applications  software,  but 
have  not  yet  been  successful  in  converting  those  needs  into 

1  °Code  45  (M  obilizat  ion /Readiness)  was  extremely  frus¬ 
trated  with  the  state  of  ku?  support  for  his  needs.  His 
RTSS/IM APHIS  experience  has  served  to  make  him  adamant  that 
any  future  RTSS  must  not  be  associated  with  or  dependent  on 
any  other  svstem.  [Ref.  23] 
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POM  items.  Money  for  AD?  has  been  cut  back  in  past  years. 
Virtually  all  ADP  funds  are  being  funnelled  into  maintaining 
the  current  inept  system.  Innovation  has  no  priority  on  the 
mobilization  battlefield. 

Code  461  is  presently  trying  to  find  the  money  to 
convert  the  file  structure  of  RTSS  from  the  RSTS/2  operating 
system  to  the  VMS  operating  system.  This  in-house,  i.e. 
non-NAVAIR,  effort  will  take  considerable  contractor 
support.  A  ?DP  11/45  stands  ready  at  New  Orleans  for 
research  and  support  in  the  conversion  efforts. 

The  DDN  problem  must  also  be  resolved.  Conversion  of 
the  current  system  to  allow  terminal  to  host  processing  or 
the  DDN  is  still  an  issue.  Estimates  for  initial  protocol 
conversion  for  the  ESTS/E  operating  system  by  various 

contractors  have  ranged  from  $ 150,  000  to  3300,000,  with 
approximately  350,  000  required  annually  for  maintenance  and 
support.  Yet  wide  area  network  interface  products  already 
exist  for  VAX  (VMS)  machines,  and  the  progress  in  local  area 
networks  for  micr ocomputers  such  as  Z-150s  yields  a  new 
product  monthly.  The  major  studies  cited  previously  in  this 
document  have  looked  at  both  Navy  and  Reserve  AIS  problems 
and  determined  that  cumbersome  redesigning  efforts  on  obso¬ 
lete  systems  are  a  waste  of  valuable  resources. 

Off-the-shelf  technology  is  available  today. 

All  of  these  issues  and  questions  can  best  be  resolved 
by  those  trained  and  experienced  in  dealing  with  them.  The 

Information  Age  is  a  reality  whose  workings  are  fast 

becoming  the  modus  operandi  for  the  Navy’s  business.  The 
fields  of  networking,  office  automation,  database  manage¬ 
ment,  and  requirements  analysis  are  full  of  pitfalls  in 
which  to  lose  valuable  time  and  money.  More  and  more 
dollars  in  the  ADP  world  are  going  towards  the  labor  costs 
of  software  maintenance,  and  less  dollars  for  hardware  that 
is  becoming  cheaper  and  more  effective.  Outside  contractor 
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sourcing  for  software  services  has  become  a  way  of  life  for 
the  Kavy.  Yet,  for  the  cost  of  some  additional  ACD'JTPA 
drills,  the  Reserves  have  many  of  those  resources  readily 
available.  There  are  many  individuals  who  are  not  only 
skilled  in  the  intricacies  of  ATS  management,  but  well 
versed  in  the  unique  needs  of  the  Reserves.  The  Information 
Systems  Support  Unit  must  be  implemented  if  the  Reserves  are 
to  efficiently  and  effectively  plan  for  the  automation  of 
training  and  mobilization. 

Software  prototyping  using  off-the-shelf  fourth  genera¬ 
tion  query  and  database  technology  is  fast  becoming  an 
acceptable  alternative  to  the  lengthy  and  complex  metnod- 
oiojy  traditionally  used.  Certainly,  no  system  can  hope  to 
be  free  from  potential  error.  Management  must  still 
control,  coordinate,  and  plan.  Isers  must  work  closely  with 
developers  until  they're  skilled  enough  to  go  it  alone.  The 
primarj  advantage  of  prototyping  is  the  ability  to  get 
results  quickly,  and  then  to  continually  change  as  problems 
arise  or,  more  likely,  needs  change.  This  cycle  of  feedback 
an  l  change  is  not  available  using  the  software  and  require¬ 
ments  analysis  techniques  of  the  past. 

B.  RECOMMENDATIONS 

Several  alternatives  face  the  Reserves  as  they  attempt 
to  fix  seme  rather  extensive  AIS  problems: 

1.  The  Reserves  could  simply  continue  on  the  present 
course  of  letting  the  Active  Navy  design  and  imple¬ 
ment  i  foiiow-cn  system,  as  may  be  the  case  with  the 
present  Source  Data  System  plans  and  efforts.  The 
Reserves  will  have  to  live  with  whatever  that  system 
becomes,  and  it  is  only  now  in  the  planning  stages 
for  including  Reserve  requirements.  However,  there 
is  a  notaole  history  of  the  Reserves  taking  a  Lack 
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seat  when  it  comes  to  sharing  common  resources;  the 
hand-me-down  nature  of  support  received  from  ATSS 
facilities  by  sharing  PTSS  sites  is  painfully  appli¬ 
cable.  The  delay  before  SD5  implementation  also 
means  another  five  years  (approximately)  of  chaos  in 
handling  training  and  mobilization  data. 

2.  A  major  effort  could  be  made  to  redesign  the  current 
applications  software  and  file  structure  to  run  on 
the  more  efficient  and  DON  compatible  VAX  (VMS)  hard¬ 
ware.  In  terms  of  dollars  and  results,  this  would 
probably  be  the  cheapest  way  to  'fix’  the  present 
disarray  of  a pplicat ions.  It  would  leave  just  that: 
a  'fixed'  antiquated  system  of  applications  with  a 
database  system  that  is  really  a  file  management 
system  and  has  little  or  no  room  for  expansion  or 
major  changes. 

3.  Re-designing  with  both  new  hardware  and  software  is  a 

third  option  which  is  not  overwhelming  when  manage¬ 
ment  acknowledges  that  they  still  must  do  things 
manually.  This  option  brings  to  the  Reserves  the 
functional  sponsorship  ox  a  system  of  their  own. 
Design  from  the  beginning  can  best  serve  their  own 
unique  needs,  both  present  and  future.  Field  plan¬ 
ning  teams,  under  the  guidance  of  an  ISSO  could 
gather  and  forward  a  set  of  initial  requirements  for 
a  prototype.  Ihe  basic  requirements  of  DDN, 

VAX  (VMS)  ,  and  (large)  microcomputer  compatibility  can 
be  met  by  several  products  on  the  market  today.  A 
benchmark  or  standard  could  be  developed  by  the  ISSO 
for  a  competitive  runoff  of  the  eligible  fourth 
generation  languages.  The  ISSU  could  then  pick  a 
candidate  to  buy  for  their  prototyping  tool,  and  the 
Reserves  would  be  on  their  *ay  to  the  1930's. 
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Vie  are  naturally  biased  in  the  selection  of  the  third  alt 
native  as  our  own  recommendation.  Our  efforts  at  pro 
typing  are  only  the  first  iteration  and  much  remains  to 
done.  '?e  were  disappointed  with  tne  lack  of  support 
found  in  the  report  writing  facility  of  the  ORACLE  softw 
package,  but  were  impressed  with  the  ease  of  prototyp 
using  a  relational  software  package.  The  next  step  in  t 
effort  should  be  to  develop  report  writing  once  the  bugs 
fixed.  Additionally,  experimentation  with  a  medium-si 
database  to  evaluate  the  efficiency  of  the  system  is  nec 
sa  r  y . 

The  I5SU  and  prototyping  will  go  a  long  way  towa 
bringing  the  Reserve  manager  of  today  some  meaningful 
leadership  and  technology.  The  recent  upgrading  of  0P- 
(Tnf ormatior.  Systems  Division)  to  a  flag  billet,  and  the 
of  new  software  productivity  tools  at  MPC-4  are  indicati 
that  the  Navy  means  business  in  its  'Battle  of  the  3yt 
Vie  strongly  urge  the  Reserves  to  take  note,  take  heart, 
move  toward  a  sounder  and  stronger  MS  future. 


er- 
to- 
be 
we 
ar  e 
ing 
nis 
are 
zed 
es- 


rds 
AIS 
945 
use 
ons 
e' . 
and 


9  1 


> JL  —i  M. . 


APPENDIX  A 

DATA  ELEMENTS  DICTIONARI 


TN  AM  r  CNAME 

COLT YP 

WIDTH 

Comment 

NA  ME  S  5  M 

NUMBER 

9 

NOT  NULL 

NAMELAST 

CHAR 

20 

NOT  NULL 

NAM  EF 

CHAR 

20 

NOT  NOLL 

NAM  EMI 

CHAR 

3 

NCI  HULL 

RANK  OR  RATE 

CHAR 

5 

NOT  NULL 

CLH ACCESS 

CHAR 

6 

PE3D 

NUMBER. 

6 

NCT  NULL 

DOE 

NUMBER 

6 

SEX 

CHAR 

1 

ETHNIC 

CHAR 

1 

RACE 

CHAR 

1 

DEPEN 

CHAF. 

2 

S  IF:  SET 

CHAP 

30 

NOT  NULL 

CITY 

CHA  R 

18 

NOT  NULL 

STATS 

CHAR 

2 

NOT  NULL 

ZIP 

NUMBER 

9 

N  OT  NULL 

HOMSPHON 

NUMBER 

10 

NOT  NULL 

R  UC 

NUMBER 

5 

TECJIC 

NUMBER 

5 

R  CD  SF  LA  G 

C  HA  3 

1 

?  R  E  C  D 

HO ME EH 

8 

P AYGR AD  E 

CHAR 

1 

EOS 

NUMBER 

6 

MOD 

NiJMEEH 

1 

EXE  AA 

NUMBER 

6 

DOR 

NUMBER 

6 

DUS  PHONE 

CHAR 

15 

CCCI 

CHA  R 

9 

PNC3C  OR  PNEC 

C  HAR 

4 

S'JBCD 

CHAF. 

5 

LINEAL 

NUMBER 

3 

CNAME 

COLTYP 

WIDTH 

Comments 

RUIC 

NUMBER 

5 

NOT 

NULL 

F,  B  S  C 

CHAR 

5 

NOT 

NULL 

0  E  INDEX 

CHAF 

1 

NOT 

N  ULL 

A?SC 

CHAR 

5 

NOT 

NULL 

NO 3 C  PNEC 

CHAR 

4 

A  F  A  I" 

CHA  R 

5 

IRATE 

CHAR 

5 

SSI! 

N  UMBER 

9 

D  E  S  C  F  i  ?  T I C  N 

CHAR 

30 

DEP  " 

CHA  R 

3 

NOT 

NULL 

t  :  j  a  e 

CNAM  E 

COLTY? 

WIDTH 

Comments 

MOBILIZE 

A  'JIG 

NUMBER 

5 

NOT  NULL 

.MOBTIME 

NUMBER 

4 

MO  BOAT E 

NUMBER 

6 

MOBEVCODE 

NUMBER 

9 

P.DD 

NUM3ER 

6 

MAJCLMT 

CHAR 

2 

MC3SPNE 

C  HA  R 

2 

ALLOFF 

NUMBER 

3 

ALLENL 

NUMBER 

3 

ADR  EOF F 

NUMBER 

1 

ADRLENL 

NUMBER 

1 

ADMSTROF 

NUMBER 

3 

ADM  STEEN 

NUMBER 

3 

T  N  A  M  2 

CNAM  E 

COLTYF 

WIDTH 

Comments 

DRILLS 

S  S  N 

NUMBER 

9 

NOT 

NULL 

DEILL7Y  RE 

C  HA  R 

1 

NOT 

N  ULL 

N  UM DS ILLS 

NUM3ER 

■> 

NOT 

N  ULL 

DRILL  DATE 

NUMBER 

6 

IN  A  M  E 

C  NAME 

COLTY? 

WIDTH 

Comment s 

ATDU7EA 

ESN 

NUMBER 

9 

NOT  NULL 

ACD JDATE 

NUMBER 

6 

NOT  NULL 

AO  DUTY  PE 

CHAR 

i 

NOT  NULL 

AC DUD A YS 

NUMBER 

2 

A  U I  C 

NUMEER 

D 

ACD  UP  AY 

CHAR 

i 

T  NAME 

CNAM  E 

COLT  YP 

W  IDTH 

Comments 

:;o3c_s:i  ec 

OS'* 

NOB  C_  0  R.  _S  N  E  C 

NUMBER 

CHAR 

9 

4 

Tii  AM  “ 

C  N  A  M  E 

COLTY? 

W  1 D  r  H 

Comme  n  t  s 

3  j  1  A‘  j  c, 

3  0  V 

NUM3EF. 

9 

NOT  NULL 

L  AN  ; 

C  ii  A  R 

NOT  NULL 

LA NGCOM I 

m  tt  *•;  p  p  - 

1 

LAN  OREAD 

N UMBER 

L  A  N  IS  ?  K 

NU.M  3FF 

1 

L  A  N  0  W  ,i  ’ 

NUMBER 

1 

1*  L-  A  P 

C  •;  A  H 

1 

1  3 


na  me 

CNAri  E 

COLTYP 

N  i  d  r  h 

Comments 

D'JC  ATION 

5  S  N 

NUMBER 

3 

NOT  NULL 

E  DUC YEAR 

NUMBER 

2 

EDOCLEV El 

CHAR 

1 

EDO  CM  A J OR 

NUMBER 

2 

NAME  CNAME 

COLTYP 

Vi  ID  TH 

Commen  t  s 

ESEF.VUNIT  RUIC 

NUMBER 

5 

NOT 

NULL 

A  U  I C 

NUMBER 

5 

NOT 

NULL 

ADDRESS 

CHA  R 

30 

NOT 

N  DLL 

C1I  Y 

CHAR 

13 

NOT 

M  DLL 

STA^E 

CHAR 

2 

NOT 

NULL 

ZIP 

NUMBER 

5 

NOT 

N  DLL 

COMM? HONE 

NUMBER 

10 

AUTOVPHCNE 

NUMBER 

7 

P  ESCENUIC 

CHAR 

5 

FUICLNA  ME 

CHAR 

25 

A  'J ICL NAME 

CHA  R 

25 

RES  CENL  NAME 

CHAR 

25 

A  PC 

C  HA  R 

7 

NAME 

CNAME 

COLTYP 

WIDTH 

C  omm 

ent  s 

'0  3  ?  TILTS 

A  U I  C 

NUMBER 

5 

NOT 

N  :JLL 

A  BSC 

CHAR 

5 

NOT 

N  rJLL 

D  SCEPTIC N 

CHAR 

30 

DESIG  RATE 

CHAR 

5 

? AYGRID  E 

CHAR 

2 

NAME 

CNAM  E 

COLTYP 

W  IDTH 

Comment  s 

E  EA  R  A  NO  E 

o  O  i\ 

NUMBER 

9 

NOT 

NULL 

CLP.  ACCESS 

CHAR 

6 

NOT 

N  ULL 

S  EC AGENCY 

C  H  A  F 

i 

NOT 

NULL 

jZC^Y?7 

C  HA  R 

i 

NOT 

N  ULL 

S  EC  D A  T  E 

NUMBER 

6 

NOT 

NULL 

APPENDIX  3 

IBTERACTIVE  APPLICATIONS  0  ENEfiATOE  OUTPUT 


FESEEVE  'JMIT  INFO?  NATION 


SIEVE  UNIT  LONG  NAME 
XXXXXXXXXXXXXXXXXXXXXXX 


3.  E S  E?  V  E  U  I 

X  X  X  X  X 


XX  X  XXXXXXXXXXX  XX  XX XX XX XXX 


COM M EECIAL  PHONE  NO. 

XX  XXX  XX  XXX 


XX XXXXXXXXXXX 


ST  ZIP 

XX  XXX XX 


ALT  O 7  0  N  PHONE  NO. 
XXXXXXX 


3E5VE  CENTEF  UIC 
XX  XXX 


XXXXXXXXXXXXXXXXXXXXX 


ACTIVE  UIC 
XXXXX 


MOTE: 


.  P  ..  A  C : 


COUNT : 


AD-A156  827 


UNCLASSIFIED 


fl  DESIGN  METHODOLOGY  AND  PROTOTYPE  FOR  THE  RESERVE 
TRAINING  SUPPORT  SVSTEH(U)  NAVAL  POSTGRADUATE  SCHOOL 
HONTEREV  CA  N  J  HINSLOH  ET  AL.  MAR  85 


MICROCOPY  RtSOLUtlOIM  TEST  CHAR] 

N.'.’i,  A;,,  imii.1  4||  .  .,nnn,4WlS  f,„.,  A 


ACDUTRA  INFORMATION 


Soc.  Sec.  No. 
xxxxxxxxx 

Type 

X 

Days 

XX 

Date 

xxxxxx 

Pay 

X 

xxxxxxxxx 

X 

XX 

xxxxxx 

X 

xxxxxxxxx 

X 

XX 

xxxxxx 

X 

xxxxxxxxx 

X 

XX 

xxxxxx 

X 

xxxxxxxxx 

X 

XX 

xxxxxx 

X 

AUIC 

xxxxx 

XXXX  X 

xxxxx 

xxxxx 

xxxxx 


Char  Mode:  Replace  Page  1 


Count:  0 


RESERVE  UNIT  BILLET  STRUCTURE 


Reserve  UIC 

R  BSC 

Off/Enl 

Description 

xxxxx 

xxxxx 

X 

XXX  XX XXXXX  XXXXX  XXX  XXX 

ABSC 

11111 

So c.  Sec.  No. 
111111111 


N03C/PNEC 

1111 


Intended  Rank/Rate 
xxxxx 


Actual  Rank/Rate 
xxxxx 


CHAR  MODE:  REPLACE  PAGE  1 


COUNT:  1 
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DRILL  INFORMATION 


SOC.  SEC.  NO.  TYPE 


XXXXXXXXX  X 

XXXXXXXXX  X 

XXXXXXXXX  X 

XXXXXXXXX  X 

XXXXXXXXX  X 


CHAR  MODE:  REPLACE  PAGE  1 


NUH3ER 

DATE 

XX 

xxxxxx 

XX 

xxxxxx 

XX 

xxxxxx 

XX 

xxxxxx 

X 

xxxxxx 

COUNT:  0 
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APPENDIX  C 

PERSONAL  INFORMATION  SCREEN 


;  *****  THIS  PROGRAM  IS  THE  INTERACTIVE  APPLICATIONS 
•  *****  GENERATOR  CODE  THAT  IS  COMPILED  TO  DEVELOP  THE 
;  *****  PERSONAL  SCREEN.  IT  HAS  A  FILE  TYPE  OF  . INP  - 
j  *****  THE  COMPILED  CODE  HAS  A  FILE  TYPE  OF  .FRM. 
;Application  Title  : 

PERSONAL  INFORMATION 
.•ORACLE  workspace  size  : 

:Block  name  /  Description  : 

PERSNAME 


; Table  name  : 

NAME 

;Check  for  uniqueness  before  inserting  Y/N  : 

N 

:Display/3uffer  how  many  records  : 

1/2  5 

;Field  name  : 

SSN 

:Type  of  field  : 

NUMBER 

^Length  of  field  /  Display  length  /  2uery  length 

:Is  this  field  in  the  base  table  Y/N  : 

Y 

^ls  this  field  part  of  the  primary  key  Y/N  : 

;Field  tc  copy  primary  key  from  : 

;Default  value  : 

^Page  : 

:Line  : 

4 

:Column  : 

55 


rPrompt  : 

Soc.  Sec.  No. 

;Display  prompt  above  field  Y/N  : 
n 

;Allow  field  to  be  entered  Y/N  ; 

y 

;SQL> 

;Is  field  fixed  length  Y/N  : 

y 

;Auto  jump  to  next  field  Y/N  : 

y 

;Convert  field  to  upper  case  Y/N  : 
n 

:Help  message  : 

r,r.ter  Member’s  Social  Security  Number  This  field  is  mandator 
;Lowest  value  : 

;Highest  value  : 


y.' 
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{Field  name  : 

NAM  SF 

^Tjge  of  field  : 

{Length  of  field  /  Display  length  /  Query  length 

12 

;Is  this  field  in  the  base  table  Y/N  : 

Y 

•Is  this  field  part  of  the  primary  key  Y/N  : 

N 

;Default  value  : 

^Page  : 

:Line  : 


{Column  : 

1o 

{Prompt  : 

First  Name 

{Display  prompt  above  field  Y/N  : 

y 

{Allow  field  to  be  entered  Y/N  : 
y 

{Allow  field  to  be  updated  Y/N  : 

y 

;SQL> 

{Is  field  mandatory  Y/N  : 

y 

;Is  field  fixed  length  Y/N  : 
n 

{Auto  jump  to  next  field  Y/N  : 
y 

{Convert  field  to  upper  case  Y/N  : 

yu  i 

•Help  message  i 

inter  Member’s  First  Name  -  Tnis  field  is  mandatory 
{Lowest  value  : 

{Highest  value  : 

{Field  name  : 

NAM  FM I 

ilKI6  ° *  : 

•Length  of  field  /  Display  length  /  Query  length  ; 
Is  this  field  in  the  base  table  Y/N  : 


Is  this  field  part  of  the  primary  key  Y/N 


ft 

{Default  value  : 

jjPage  : 

^Line  : 

{Column  : 

23 

{Prompt  : 

MI 

^Display  prompt  above  field  Y/N 


Allow  field  to  be  entered  Y/N  : 
Allow  field  to  be  updated  Y/N  : 
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;SQL> 

;Is  field  mandatory  Y/N  : 

N 

:Is  field  fixed  length  Y/N  : 

Y 

^Auto  jump  to  next  field  Y/N  : 

^Convert  field  to  upper  case  Y/N  ; 

Y 

:Help  message  : 

Enter  Member’s  Middle  Initia 1- Leave  blank  if  unknown  or  NMN 
;Lowest  value  : 

;Highest  value  : 

:Field  name  : 

NAME1AST 

inlf6  °*  : 

^Length  of  field  /  Display  length  /  Query  length  : 

:Is  this  field  in  the  base  table  Y/N  : 

Y 

jjls  this  field  part  of  the  primary  key  Y/N  : 

;Default  value  : 

^Page  : 

^Line  : 

/ 

:Coiumn  : 

i 6 

jPrompt  : 

Last  Name 

;Display  prompt  above  field  Y/N  : 
y 

; Allow  field  to  be  entered  Y/N  : 
y 

;Allow  field  to  be  updated  Y/N  ; 

y 

;SQL> 

;Is  field  mandatory  Y/N  : 
y 

;Is  field  fixed  length  Y/N  : 
n 

;Auto  jump  to  next  field  Y/N  : 
y 

;Convert  field  to  upper  case  Y/N  ; 

yu  , 

:Help  message  : 

Enter  Member's  Last  Name  -  This  Field  is  Mandatory! 

;Lowest  value  : 

;Highest  value  : 

:Field  name  : 

RANK  OR  RATE 
:Tvpe  of  field  : 

^Length  of  field  /  Display  length  /  Query  length  : 

:Is  this  field  in  the  base  table  Y/N  : 

Y 

^Is  this  field  part  of  the  primary  key  Y/N  : 

;Defauit  value  : 
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^Page  : 

:Line  : 

7 

:Column  : 

§0 

•Prompt  : 

Rank/Hate 

;Display  prompt  above  field  Y/N  : 
y 

;Allow  field  to  be  entered  Y/N  : 
y 

;Allow  field  to  be  updated  Y/N  : 
y 

;SQL> 

;ls  field  mandatory  Y/N  : 
y 

;Is  field  fixed  length  I/N  : 
n 

;Auto  jump  to  next  field  Y/N  : 
y 

;Convert  field  to  upper  case  Y/N  : 
y 

:Heip  message  : 

Enter  Member's  Rank  or  Rate-  LCDR ,  CAPT,  ABHCS,  3M2,  etc. 
;Lowest  value  : 

;Highest  value  : 

:Field  name  : 

RCDSFIAG 
(jT^ge  of  field  : 

jLength  of  field  /  Display  length  /  Query  length  : 

;Is  this  field  in  the  base  table  Y/N  : 

i 

^Is  this  field  part  of  the  primary  key  Y/N  : 

:Default  value  : 

A 

jPage  : 

^Line  : 

•.Column  : 

&6 


jPrompt  : 
Status 


gDisplay  prompt  above  field  Y/N  ; 
i 

;Allow  field  to  be  entered  Y/N  : 

Y 

^Ailow  field  to  be  updated  Y/N  : 
;SQL> 

^Is  field  mandatory  Y/N  : 

:  Is  field  fixed  length  Y/N  : 

Y 

^Auto  jump  to  next  field  Y/N  : 
^Convert  field  to  upper  case  Y/N  : 


:Help  message  : 
A-  Active,  D-  A 


waiting  Deletion 
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Lowest  value 


[Highest  value  : 


;Field  name  : 
STREET 

dill6 


^Length  of  field  /  Display  length  /  Query  length 


:Is  this  field  in  the  base  table  Y/N 
Y 


Is  this  field  part  of  the  primary  key  Y/N  : 


;Default  value 


^Page  : 


:Lme  : 

^0 

:Column  : 

^0 

:Prompt  : 

Street 

;Display  prompt  above  field  Y/N 


;Ailow  field  to  be  entered  Y/N  : 

y 

;Allov  field  to  be  updated  Y/N  : 

y 

;SQL> 


;  Is  field  mandatory  Y/N  : 

Y 

;  Is  field  fixed  length  Y/N  ; 


^Auto  jump  to  next  field  Y/N 


^Convert  field  to  upper  case  Y/N  : 


:Help  message  : 
Enter  Member’s 


;Lowest  value 
;Kighest  value 


Street  Address-  This  Field  is  Mandatory 


; Field  name  : 
CITY 

£h&Ig 


^Length  of  field  /  Display  length  /  Query  length 


;Is  this  field  in  the  base  table  Y/N 


Is  this  field  part  of  the  primary  key  Y/N  : 


;Default  value  : 


•Page  : 

:Line  : 

^3 

:Column  : 

1 \0 

;Prompt  : 

City 

;Display  prompt  above  field  Y/N  : 
y 

:Allow  field  to  be  entered  Y/N  : 


^Allow  field  to  be  updated  Y/N  ; 

;SQL> 

|Is  field  mandatory  Y/N  : 

:Is  field  fixed  length  Y/N  : 

N 

;Auto  jump  to  next  field  Y/N  : 

Y 

^Convert  field  to  upper  case  Y/N  : 

:Heip  message  : 

Enter  Member's  City-  This  field  is  mandatory! 
;Lowest  value  : 

;Highest  value  : 

:Field  name  : 

State 

^Length  of  field  /  Display  length  /  Query  length 

2. 

;Is  this  field  in  the  base  table  Y/N  : 

Y 

^Is  this  field  part  of  the  primary  key  Y/N  : 
;Defauit  value  : 

^Page  : 

:Line  : 

13 

;Column  : 

3o 

:Prompt  : 

ST 

^Display  prompt  above  field  Y/N  ; 

:Allov  field  to  be  entered  Y/N  : 

Y 

^Allow  field  to  be  updated  Y/N  : 

;  SQL> 

:Is  field  mandatory  Y/N  : 

T 

^Is  field  fixed  length  Y/N  : 
jAuto  jump  to  next  field  Y/N  : 

^Convert  field  to  upper  case  Y/K  ; 

:Help  message  : 

Enter  Member's  State-  This  field  is  mandatory! 
;Lowest  value  ; 

jh'ighest  value  : 

:Field  name  : 

ZIP 

:Type  of  field  : 

NUMBER 

^Length  of  field  /  Display  length  /  Query  length 
:Is  this  field  in  the  base  table  Y/N  : 


105 


;Is  this  field  part  of  the  primary  key  Y/N  : 

N 

;Default  value  : 

^Paye  : 

:Line  : 

13 

:Column  : 

34 

;Prompt  : 

ZIP 

^Display  prompt  above  field  Y/N  : 

;Allov  field  to  be  entered  Y/N  : 

Y 

^Allov  field  to  be  updated  Y/N  : 

;  SQL> 

;Is  field  mandatory  Y/N  : 

Y 

;Is  field  fixed  length  Y/N  : 

Y 

;Auto  jump  to  next  field  Y/N  : 

Y 

:Convert  field  to  upper  case  Y/N  : 

N 

;Help  message  : 

Snter  Member’s  ZIP  Code-  This  field  is  Mandatorv 
;Lowest  value  : 

; Highest  value  : 

;Field  name  : 

HOME?  HON 

;Type  of  field  : 

NUMBER 

^Length  of  field  /  Display  length  /  Query  length 

; Is  this  field  in  the  base  table  Y/N  : 

Y 

;Is  this  field  part  of  the  primary  key  Y/N  : 

N 

;Oefault  value  : 


^Paje  : 

:Line  : 

1o 

:Column  : 

^Prompt  : 

Home  Phone 

;Display  prompt  above  field  Y/N  : 
y 

;Allow  field  to  be  entered  Y/N  : 
y 

;Allow  field  to  be  updated  Y/N  : 
';SQL> 

;Is  field  mandatory  Y/N  : 
n 

;Is  field  fixed  length  Y/N  : 
y 

;Auto  jump  to  next  rield  Y/N  : 
y 

;Convert  field  to  upper  case  Y/N  ; 
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in  this  Format-  18005551272 


:Help  message  : 

Enter  Member's  Home  Phone 
;Lowest  value  : 

;Kighest  value  : 

:Field  name  : 

3'JSPHONE 
;Tvpe  of  field  : 

NDMsZE 

•Length  of  field  /  Display 
Is  this  field  in  the  base 


;Is  this  field  part  cf  the 

a 

;Default  value  : 

^Page  : 


length  /  Query  length  : 
table  Y/N  : 
primary  key  Y/N  : 


:Line  : 

^  3 

:  Column  : 

*0 

pPrompt  : 

Business  Phone 

; Display  prompt  above  field  Y/N  : 
y 

;Allow  field  to  be  entered  Y/N  : 
fallow  field  to  be  updated  Y/N  : 

IsQL> 

;Is  field  mandatory  Y/N  : 
n 

;Is  field  fixed  length  Y/N  : 
n 

;Auto  jump  to  next  field  Y/N  : 
v 

jConvert  field  to  upper  case  Y/N  : 
n 

;Help  message  : 

Enter  Member's  Business  Phone  in  this  Fora  at- 18  0 05 55 1 2  1 2x21  2 1 
;Lowest  value  : 

; Highest  value  : 

:Field  name  : 

ROIC 

;Type  of  field  : 

NUMBER 

^Length  of  field  /  Display  length  /  Query  length  : 

:Is  this  field  in  the  base  table  Y/N  : 

Y 

j|Is  this  field  part  cf  the  primary  key  Y/N  : 

;DefauIt  value  : 

^Page  : 

-.Line  : 

16 

:Column  : 

:?rompt  : 

Reserve  UIC 
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APPENDIX  D 
PROTOTYPE  INDICES 


Index 

Name 

Table 

Na  me 

Co lumn 

Name 

Index 

Type 

NAM  E_F.UIC 

NAME 

RUIC 

NON 

UNIQUE 

NAM2_ZIP 

NAME 

ZIP 

NON 

UNIQUE 

NAM  E_SSN 

NAME 

SSN 

UNIQUE 

S3 N_ LANG 

LANGUAGE 

SSN 

NON 

UNIQUE 

LANG_SSN 

LANGUAGE 

LANG 

NON 

UNIQUE 

SSN_EDUCATION 

EDUCATION 

SSN 

NON 

UNI*i  UE 

NA.M  E_TEUIC 

NAME 

TRUIC 

HON 

UNIQUE 

CLR_  SSN 

CLEARANCE 

SSN 

NON 

UNIQUE 

DRILL_SSN 

DRILLS 

SSN 

NON 

UNIQUE 

DRILL_NUM 

DRILLS 

NUMDRILLS 

NON 

UNIQUE 

120 


;Field 

;Block 

%END 


name  : 

name  /  Description  : 

-----  -  PERSONAL  INFORMATION 
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[Line  : 
*1 

•Column 

Jo 

;  Prompt 
COCI 


i 


Display  prompt  above  field  Y/N  : 

Allow  field  to  be  entered  Y/N  ; 

Y 

^Allow  field  to  be  updated  Y/N  : 

;  SQL> 


Is  field  mandatory  Y/N  : 

Is  field  fixed  length  Y/N  : 

Auto  jump  to  next  field  Y/N  : 
Convert  field  to  upper  case  Y/N 


ft 

[Help  message  : 
inter  Member's  COCI 
;Lowest  value  : 

[Highest  value  : 

: Field  name  : 

SOBCD 

^Tjge  of  field  : 

^Length  of  field  /  Display  length  /  Query  length 

:Is  this  field  in  the  base  table  Y/N  : 

$ 

Is  this  field  part  of  the  primary  key  Y/N  : 

[Default  value  : 

j^Page  : 

[Line  : 

[Column  : 

[Prompt  ; 

Subspecialty 

.•Display  prompt  above  field  Y/N  ; 

y 

[Allow  field  to  be  entered  Y/N  : 

y 

[Allow  field  to  be  updated  Y/N  : 

h  QL> 

[Is  field  mandatory  Y/N  : 
n 

[Is  field  fixed  length  Y/N  : 
n 

[Auto  jump  to  next  field  Y/N  : 

y 

[Convert  neld  to  upper  case  Y/N  : 
n 

[Help  message  : 

inter  member's  Subs^ecialty  Code 
[Lowest  value  : 

[Highest  value  : 
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N 

•Is  field  fixed  length  Y/N  : 

N 

^Auto  jump  to  next  field  Y/N  : 

:Convert  field  to  upper  case  Y/N 
N 

;Help  message  : 

Enter  Member’s  Lineal  Number 
;Lowest  value  ; 

;Kighest  value  : 

gField  name  : 

£nobc^cr_pnec 

itt 


>e  of  field 


length  of  field  /  Display  length  /  Query  length 
Is  this  field  in  the  base  table  Y/N  : 


4 
£ 

;Is  this  field  part  cf  the  primary  key  Y/N  ; 
N 

jDefault  value  : 

^Page  : 

:Line  : 

\Q 

;Column  : 

Ee 

:Prompt  : 

NOBC/PN  EC 

^Display  prompt  above  field  Y/N  : 

:Allow  field  to  be  entered  Y/N  : 

Y 

•Allow  field  to  be  updated  Y/N  : 

Y 

;SQL> 

•Is  field  mandatory  Y/N  : 

N 

: Is  field  fixed  length  Y/N  : 

N 

gAito  jump  to  next  field  Y/N  : 

Y 

Convert  field  to  upper  case  Y/N  : 


Primary  N03C  or  NEC 


•Help  message  : 

Enter  Member's 
.-Lowest  value  : 

; Highest  value  : 

:Field  name  : 

COCI 

^Tjjoe  of  field  : 

^Length  of  field  /  Display  length  /  Query  length 

:Is  this  field  in  the  base  tatle  Y/N  : 

Y 

^Is  this  field  part  of  the  primary  key  Y/N  : 
;Default  value  : 

:?age  ; 
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;Ty  pe  of  field  : 


.eng 

Is  this  field  in  the  base  table  Y/N  : 


^Length  of  field  /  Display  length  /  Query  length 


;Is  this  field  part  of  the  primary  key  Y/N 
N 

;Defauit  value  : 

^Page  : 

:Line  : 

15 

:Column  : 

$8 

:Prompt  : 

EXEAA 

^Display  prompt  above  field  Y/N  : 

:Allow  field  to  be  entered  Y/N  : 


Allow  field  to  be  updated  Y/N 
SQL> 

Is  field  mandatory  Y/N  : 

Is  field  fixed  length  Y/N  : 


;Auto  jump  to  next  field  Y/N  : 

^Convert  field  to  upper  case  Y/N  : 

:Help  message  : 

nnter  Member’s  EXRAA-  YYMMDD 

;Lowest  value  : 

;Highest  value  : 

jrield  name  : 

LINEAL 

HUf o£  fieU 


_ IEB 

Length  of  field  /  Display  length  /  Query  length 
Is  this  field  in  the  base  table  Y/N  : 
is  this  field  part  of  the  primary  key  Y/N  : 


N 

; Default  value  : 
j?age  : 

:Lir.e  : 

1 3 

:Column  : 

io 

^Prompt  : 
nineal  No. 

.•Display  prompt  above  field  Y/N  : 
y 

;Allow  field  to  be  entered  Y/N  : 

Y 

^Allow  field  to  be  updated  Y/N  : 

;  3QL> 

;Is  field  mandatory  Y/N  : 
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20 

jPromct  : 

Precedence  Mo. 

;Displav  prompt  above  field  Y/N  : 

y 

;Allow  field  to  be  entered  Y/N  : 

Y 

:Allov  field  to  be  updated  Y/N  : 

Y 

;  SQL> 

^Is  field  mandatory  Y/N  : 

•Is  field  fixed  length  Y/N  : 

N 

;Auto  jump  to  next  field  Y/N  : 

Y 

•Convert  field  to  upper  case  Y/N  : 

N 

•Help  message  : 

Enter  Member’s  Precedence  Number 
;Lowest  value  : 

;Highest  value  : 

;Field  name  : 

MOD 

:?ype  of  field  : 

NUMB  EE 

•Length  of  field  /  Display  length  /  ^uery  length 

;Is  this  field  in  the  base  table  Y/N  : 

Y 

;Is  this  field  part  of  the  primary  key  Y/N  : 
;Default  value  : 
gPage  : 

4L 

jLine  : 

Is 

:Column  : 

4o 

•Prompt  : 

MOD 

^Display  prompt  above  field  Y/N  : 

:Allov  field  to  be  entered  Y/N  : 

Y 

^Ailow  field  to  be  updated  Y/N  : 

;SQL> 

:Is  field  mandatory  Y/N  : 

N 

|Is  field  fixed  length  Y/N  : 

|Auto  jump  to  next  field  Y/N  : 

^Convert  field  to  upper  case  Y/N  : 

:Help  message  ; 

Enter  Member’s  MOD 
;Lowest  value  : 

;Bighest  value  ; 

jField  name  : 

EXRAA 
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V  V 


;Auto  jump  to  next  field  Y/N  : 

Y 

^Convert  field  to  upper  case  Y/N  : 

:Help  message  : 

Enter  Member’s  Date  of  Rank  or  Rate-  YYMMDD 
;Lowest  value  : 

;Highest  value  : 

;Field  name  : 

EOS 


>e  of  field  : 
5ER 


tSI: 

^Length  of  field  /  Display  length  /  Query  length 


jls  this  field  in  the  base  table  Y/N  : 

Y 

:Is  this  field  part  of  the  primary  key  Y/N  : 

;Default  value  : 

:Paae  : 

2  ' 

;Line  : 

^2 

;Column  : 

58 

:Prompt  : 

EOS 

^Display  prompt  above  field  Y/N  : 

;  Allow  field  to  be  entered  Y/N  : 

$ 

^Aliow  field  to  be  updated  Y/N  : 

;SQL> 

Ts  field  mandatory  Y/N  : 


Is  field  fixed  length  Y/N 


ft 
\ 

^Auto  jump  to  next  field  Y/N  : 
^Convert  field  to  upper  case  Y/N 


:Help  message  : 

Enter  Member’s  Expiration  Of  Service 
;Lowest  value  ; 

;Highest  value  : 

;Field  name  : 

PRECD 

:Type  of  field  : 

NUMBER 

^Length  of  field  /  Display  length  /  Query  length 

;Is  this  field  in  the  base  table  Y/N  : 

Y 

j^Is  this  field  part  of  the  primary  key  Y/N  : 
jDefault  value  : 
jpage  : 

:Line  : 

15 

jColumn  : 
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;  Is  this  field  in  the  base  table  Y/N  : 

Y 

; is  this  field  part  of  the  primary  key  Y/N  : 

ft 

•.Default  value  : 

:Page  : 

2 

;Line  : 

12 

:Column  : 

io 

pPrompt  : 

Pay  Grade 

;Drsplay  prompt  above  field  Y/N  : 

y.. 


ft 


Allow  field  to  be  entered  Y/N  : 


.Allow  field  to  be  updated  Y/N 

ft 

;SQL> 


ft 


Is  field  mandatory  Y/N  : 
Is  field  fixed  length  Y/N 


:Auto  jump  to  next  field  Y/N  : 

ft 

;Convert  field  to  upper  case  Y/N  : 

ft 

;Help  message  :  , 

Inter  Member's  Pay  Grade  from  Appendix 
;Lowest  value  : 

;Highest  value  : 

;?ieid  name  : 
f)OR 

;Type  of  field  : 

5?  n  d  EB 

^Length  of  field  /  Display  length  /  Query  length 

; is  this  field  in  the  base  table  Y/N  : 
ft 

;  is  this  field  part  of  the  primary  key  Y/N  : 

ft 

;Default  value  : 

:Page  : 

2 

;Line  : 

12 

;Coiumn  : 

4o 

:Prompt  : 

Date  of  Sank 

•Display  prompt  above  fieid  Y/N  : 

;Allow  field  to  be  entered  Y/N  : 

ft 

:Allow  field  to  be  updated  Y/N  : 

ft 

;SQL> 


ft 


;  Is  field  mandatory  Y/N  : 

Is  field  fixed  length  Y/N  : 
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> 


^Display  prompt  above  field  Y/N  : 

;Allov  field  to  be  entered  Y/N  : 

I 

:Allow  field  to  be  updated  Y/N  : 

Y 

;S  QL> 


Is  field  mandatory  Y/N  : 

Is  field  fixed  length  Y/N  : 


^Auto  jump  to  next  field  Y/N  : 

^Convert  field  to  upper  case  Y/N  : 

;Help  message  : 

Enter  Member’s  Dependency  Code 
;Lowest  value  : 

;Highest  value  : 

:Field  name  : 

CLKACCESS 

•length  of  field  /  Display  length  /  Query  length 


Is  this  field  in  the  base  table  Y/N  : 


£ 

j;Is  this  field  part  of  the  primary  key  Y/N  : 

;Default  value  : 

^Page  : 

•Line  : 

pColumn  : 

{Prompt  ; 

Clearance 

;Display  prompt  above  field  Y/N  ; 

V 

;Allow  field  to  be  entered  Y/N  : 

Y 

^Allov  field  to  be  updated  Y/N  : 

;  SQL> 

^Is  field  mandatory  Y/N  : 

^Is  field  fixed  length  Y/N  : 

^Auto  jump  to  next  field  Y/N  : 

:Convert  field  to  upper  case  Y/N  : 

I 

:Help  message  : 

ONCLAS. CCNFID, SECRET  , TOPS  EC 
;Lowest  value  : 

jHighest  value  : 

: Field  name  : 

PAYGEABE 

°f  : 

;Length  of  field  /  Display  length  /  Query  lengtn 
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•Help  message  : 

C-  Caucasian,  B-  Black,  0-  Oriental,  H-  Hispanic 
[Lowest  value  : 

B 

[Highest  value  : 

0 

[Field  name  : 

PSBD 

[Type  of  field  : 

NUMBER 

^Length  of  field  /  Display  length  /  Query  length 

[Is  this  field  in  the  base  table  Y/N  : 

Y 

:Is  this  field  part  of  the  primary  key  Y/N  : 

N 

[Default  value  : 

^Page  : 

:Line  : 

9 

[Column  : 

[Prompt  : 

PE3D 

^Display  prompt  above  field  Y/N  : 

[Allow  field  to  be  entered  Y/N  : 

Y 

|Allow  field  to  be  updated  Y/N  : 

[  SQL> 

[Is  field  mandatory  Y/N  : 

^Is  field  fixed  length  Y/N  : 

^Auto  jump  to  next  field  Y/N  : 

[Convert  field  to  upper  case  Y/N  : 

N 

•Help  message  : 

Enter  Member’s  Pay  Entry  Base  Date 
[Lowest  value  : 

[Highest  value  : 

[Field  name  : 

DEPEN 

^T^|e  of  field  : 

^Length  of  field  /  Display  length  /  Query  length 

[Is  this  field  in  the  base  table  Y/N  : 

Y 

^Is  this  field  part  of  the  primary  key  Y/N  : 
[Default  value  : 

^Page  : 

[Line  : 

9 

[Column  : 

4o 

[Prompt  : 


;Is  this  field  part  of  the  primary  key  Y/N  : 

N 

;Default  value  : 

[Page  : 

2 

^Line  : 

:Column  : 

4o 

jPrompt  : 
sex 

^Display  prompt  above  field  Y/N  : 

:Allow  field  to  be  entered  Y/N  : 

Y 

^Allow  field  to  be  updated  Y/N  : 

;  SQL> 

:Is  field  mandatory  Y/N  : 

N 

jls  field  fixed  length  Y/N  : 

^Auto  jump  to  next  field  Y/N  : 

^Convert  field  to  upper  case  Y/N  : 

:Help  message  : 
n-  Male  F-Female 
jLowest  value  : 

F 

;Kighest  value  : 

H 

:Field  name  : 

SAC  S 

^Tjrpe  of  field  : 

^Length  of  field  /  Display  length  /  Query  length 

:  Is  this  field  in  the  base  table  Y/N  : 

Y 

:Is  this  field  part  of  the  primary  key  Y/N  ; 

N 

;Default  value  : 

^Page  : 

^Line  : 

;Column  : 

So 

jPrompt  : 

Race 

^Display  prompt  above  field  Y/N  ; 
i 

jAllow  field  to  be  entered  Y/N  ; 

|Allow  field  to  be  updated  Y/N  : 

;SQL> 

j^Is  field  mandatory  Y/N  : 

^Is  field  fixed  length  Y/N  : 

^Auto  jump  to  next  field  Y/N  : 

;Convert  field  to  upper  case  Y/N  : 


g/y/o 

;Is  this  field  in  the  base  table  Y/N  ; 

N 

;Default  value  : 

^Page  : 

^Line  : 
iCoiumn  : 

36 

•Prompt  : 

Soc.  sec.  No. 

;  Display  prompt  above  field  Y/N  : 
n 

:  Allow  field  to  be  entered  Y/N  : 

N 

;SQL> 

:Field  name  : 

DOB 

:Type  of  field  : 

NU8BEB 

^Length  of  field  /  Display  length  /  Query  length 

:Is  this  field  in  the  base  table  Y/N  : 

Y 

^Is  this  field  part  of  the  primary  key  Y/N  : 
;Defauit  value  : 

^Page  : 

^Line  ; 

:Column  : 

3o 

;Prompt  : 

Birth  Date 

^Display  prompt  above  field  Y/N  : 

:Allow  field  to  be  entered  Y/N  : 

Y 

^Ailov  field  to  be  updated  Y/N  ; 

;SQL> 

:Is  field  mandatory  Y/N  : 

N 

|Is  field  fixed  length  Y/N  : 

|Auto  jump  to  next  field  Y/N  : 

^Convert  field  to  upper  case  Y/N  : 

:HelD  message  : 

Enter  Member's  Birth  Date  in  this  Format-  YYNNDD 
;  Lowest  value  : 

; Highest  value  ; 

:Field  name  : 
oEX 

i&P  of  field  : 

^Length  of  field  /  Display  length  /  Query  length 
:  Is  this  field  in  the  base  table  Y/N  : 


;Display  prompt  above  field  Y/N  : 

;Allow  field  to  be  entered  Y/N  ; 

Y 

^Allow  field  to  be  updated  Y/N  : 

;SQL> 

:Is  field  mandatory  Y/N  : 

H 

|Is  field  fixed  length  Y/N  : 

^Auto  jump  to  next  field  Y/N  : 

;Convert  field  to  upper  case  Y/N  : 

N 

:Help  message  : 

Enter  Member's  Reserve  Unit  Identification  Code 
;Lowest  value  : 

;Highest  value  : 

;Field  name  : 

T3UIC 

;Tvpe  of  field  : 

NUMBER 

^Length  of  field  /  Display  length  /  Query  length  : 

:Is  this  field  in  the  base  table  Y/N  : 

Y 

:Is  this  field  part  cf  the  primary  key  Y/N  : 

N 

;Default  value  : 

^Page  : 

;Line  ; 

16 

:Column  : 

$4 

jPrompt  : 
training  UIC 

;Display  prompt  above  field  Y/N  : 
y 

;Aliow  field  to  be  entered  Y/N  : 

Y 

^Allow  field  to  be  updated  Y/N  : 

;SQL> 

;Is  field  mandatory  Y/N  : 

N 

^Is  field  fixed  length  Y/N  ; 

;Auto  jump  to  next  field  Y/N  : 

;Convert  field  to  upper  case  Y/N  : 

N 

:Help  message  : 

tnter  Member's  Training  RUIC  if  it  is  Different  from  RUIC 
;Lowest  value  : 

;Highest  value  : 

:Field  name  : 

SSN 

:Type  of  field  : 

NUMBER 

;Length  of  field  /  Display  length  /  Query  length  : 
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